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Steven Brower, State Bar #93568 

Brian Barrow. State Bar #177906 

STEPHAN, ORMG3HHRRICHMAN & THEODORA 

A Professional Corporation 

535 Anton Boulevard, Suite 800 

Costa Mesa, California 92626 

Telephone: (714)241-0420 

Attorneys for Defendants 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONE> INC., ) CASENO: 02CC15350 

Judge David H. Brickner 
Plaintiff, \ Dept. C17 

V S } DECLARATION OF DAN 

,, T ^,, vv ,., 1 _ _ ) KUYKENDALL IN OPPOSITION TO 

NT OBJECTIVES, INC, et al, ) OSC RE: PRELIMINARY 

INJUNCTION 



Defendants. 



Date: October 25, 2002 

Time: 3:00 p.m 

Dept: C17 



1. Dan Kuykendall, declare: 

L Hie ficts stated herein are of my own personal knowledge except for those set forth 
onm&rmatbn and belief, and as to any such facts, I have a basis for believing that they are true. 
If called upon to testify as a witness I could and would con^etently do so as set forth herein. 

ROLFTN TRTS T THGATION 

2. I am individually named as a- defendant in this matter, 

3. I was employed by Plaintiff Foundstone, Inc. from August 2001 until July 1, 2002, 
as more fully set forth below. Iwas never an officer or director of that company. 
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1 L Before I started on a now project at Foundstone, I was usually given a list of the 
desied featuies. I was not told what algorithms to use or how to make those features actually come 
into existence in the software. I was expected to figure out, based on my prior knowledge and 
experience, how to make the computer program do what was ejected. 

12. One of the features on which I worked was the FoundScan web portal (aka 
Bpeiience). When I started I wrote the web interface to scan management in about three weeks . 
It was a good application, but there was nothing I did which was not the implementation of 
genecaty known computer programming practices. Moreover, the NTO toolkit does not have any 
web portaL 

13, Aflerlhat 1 helped with various tasks related to fixing and/or upgrading other parts 
of software programs at Foundstone. This included the creation of VhlnTrak, a program which 
maintains recoids of vulnerabilities reported in client conputer systems . It took me about a month 
to write the VulnTrafc computer program. Once again, while it is a good implementation, there are 
no algorithm or methods used in that co mputer pro gram which, in my experience, are not already 
generally known to good programmers with experience in database programming. 

14 I was never asked to participate in the preparation of any application for a patent 
whife lwas at Foundstone. I have never been advised that I am named as the "inventor 1 ' on any 
patent application filed by Foundstone. 

FOUNDSTQNgS ALLEGED TRAPES EGRETS 

15. Ihave read the Declaration of Stuart McChue submitted in support of this OSC re: 
Preliminary Injunction. From review of that document I am unable to deternnine any specific 
method, a^orithmortechnique which is being referred to by Foundstone as a trade secret, with the 
possible exception of Foundscore. However* NTO isn't doing anything like Foundscore. 

16. As stated above, the w^\^bdch I did while I was employed by Foundstone was good 
programming, but the methods, techniques and algorithms which I used were the same as those I 
would expect would be used by any other excellent experienced programmer. 

17. The Mcdure declaration gives the impression that Foundstone might be claiming 
HTML as a trade secret. The pages which display on the world wide web are mostly HTML All 
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of the HTML techniques that I used at Foundstone were standard. No new ground was broken 
there. All of the HTML I have done at NTO is, likewise, standard programming techniques. 

18. During the entire time I was employed by Foundstone I never saw any documents, 
souxce code or other material with any "trade secret" or "secret* * designation. 

DECISION TO LEAVE FOUNDS TONE AND JOIN NTO 

19. My conmite to the Foundstone office was too far. When I learned that nry wife and 
Iweaegoiigtohaveababy I wanted to be closer to home so that I could assist my wife. I had told 
Foundstone, even during my initial interview, that I wanted to telecommute. However, I was only 
abte to maintain the right to telecommute two days a week by threatening to quit. This made me 
uncomfoitabfe withny position at Foundstone. Moreover, I found the pace of work at Foundstone 
to befiustotiag. Iwould have little to do for an extended period of time while management created 
a document stating what features they wanted in the software. Then I would need to work 
frantically, for a couple of months, actually creating the program 

20. Ihad no contact with JD, or anyone else at NTO a regarding potential employment, 
until after I left Foundstone. I gave my two week notice in mid-June. Our baby was bom on 
June 27, 2002 and my last day at Foundstone was July 1, 2002. 

21. Aferlleftn^^ipbyiient at Foundstone I started to look for other employment. For 
a period of time I tried to work from my home but I decided I needed a more steady income. I 
contacted JD who I knew had started NTO after he left Foundstone. He told me that he was 
interested but that I would need to wait untilhe had enough money to fund a position for me. 

22. I subsequently joined NTO where I am presently the Senior Internet Software 
Engineer, 

23. Wehave^as a result of this litigation, been required to spend time meeting with our 
legal counsel Based on those discussions, and based on my discussions with the other employees 
ofNT0 3 audbased on my knowledge of computer programming and computer techniques, neither 
I, norany otherpeison at NTO, is utilizing anything which I understand to constitute a trade secret 
of Foundstone in the furtherance of the business of NTO. 
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Steven Brower, State Bar #93568 
Brian Barrow, State Bar #177906 

STEPHAN, OR1NGHER RICHMAN & THEODORA 

A Professional Corporation 
535 Anton Boulevard, Suite 800 
Costa Mesa, California 92626 
Telephone: (714)241-0420 

Attorneys for Defendants 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONE,INC., \ CASE NO: 02CC153S0 

M . • ) Judge David H. Brickner 

Plaintiff, \ DeptC17 

vs - ) DECLARATION OF MICHAEL J. 

MORTON IN OPPOSITION TO OSC 



NT OBJECTIVES, INC, etaL, ) RE: PRELIMINARY INJUNCTION 

Date: Oct< 
Time: 3:00 
Dept: C17 



Defendants. \ Date:. October 25, 2002 

Time: 3:00 p;m. 



I, Michael J. Morton, declare: 

1 . The facts stated herein are of my own personal knowledge except for those set forth 
on information and belief, and as to any such facts, I have a basis for believing that they are true. 
If called upon to testify as a witness I could and would competently do so as set forth herein. 

ROLE IN THIS LITIGATION 

2. I am individually named as a defendant in this matter. 

3. I was employed by Plaintiff Foundstone, Inc. from January 2001 until June 2002, as 
25 1 more fully set forth below. I was never an officer or director of that company. 
26 
27 
28 n 
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BACKGRO UND IN COMPTJTKRS 

4. I received a bachelors degree (Phi Beta Kappa) in Information and Computer Science 
fiom the University of California at Irvine in June, 1 994. 

5. I have been involved with computers since 1 982. Prior to entering college I was fluent 
with several computer assembly languages (6502, Z-80, 8088, 6809) and with microcomputer 
architecture. I had written computer programs that dealt with: graphics and realtime video chip 
programming; hardware interrupts; an 80486 assembler; dabbled in TTL/CMOS logic design; 
designed several circuits. 

6. Since before college, and throughout my career, I have been evolving a program that 
does ray traced graphical rendering. This is a 3-D technique where you "draw" a ray of light with 
sufficient detail so that the final image has shadows, shading, perspective and reflections, all 
generated automatically. Part of the program includes the creation and implementation of a 
"description language," which is similar to creating a new computer programming language and a 
new computer program which understands that language and causes the computer to do what has 
been requested. 

7. I worked for Quarterdeck Corporation from June 1994 to October 1996 as a staff 
programmer. I learned about Windows prograniming and TCP/IP programming. During this 
employment I wrote a PPP layer to the Winsock product, which is a networking protocol related to 
Windows. 

8. I worked for Connect3 from October 1996 to April 1997 as a software engineer. I 
learned database programming including ODBC and SQL. 

9. I worked for Beckman (now Beckman/Coulter) from April, 1997 to February, 2000 
as a senior software engineer. I did mote database prograniming (ODBC, Oracle and SQL Server), 
more networking (TCP/IP) and user interface Windows programming. I learned COM and ATL. 
All of this was done for a DNA Sequencer product referred to as the CEq-2000. 

10. I worked for HiHo.com from February 2000 to December 2000 as a senior software 
engineer. I learned HTML, DHTML, ASP, Winlnet, MTS and ActiveX, among others. The 
application we were working on was a distributed enterprise web application with a SQLServer 
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database. This job, in my mind, represented a culmination of my prior experience with various 
computer technologies and added several new ones to my repetoire (all having to do with web 
programming.) 

KMPT OYMENT TIV FOUNDSTONE 
U. IwashappywithmyemploymentatHiHo. However, it was a casualty of the dot com 
decline. On the day that it became apparent to me that HiHo was dissolving, I received a telephone 
call from Bernard Lee, a recruiter, who pointed me to Foundstone. 

12. After a lengthy background check I began to work for Foundstone in mid-January 
2001. 1 was a senior software engineer for the first 3 months then chief software engineer after that. 

13. Before I started on a new project at Foundstone, I was usually given a list of the 
desired features. I was not told what algorithms to use or how to make those features actually come 
into existence in the software. I was expected to figure out, based on my prior knowledge and 
experience, how to make the computer program do what was expected. 

14. While employed by Foundstone I designed and implemented a reporting mechanism 
which I am informed and believe they are still using. Foundstone had previously obtained this 
functionality by using a software program from an outside vendor, but Foundstone wanted to save 
money. Substantial portions of the software I wrote for Foundstone were based upon work I had 
done while working for Beckman. All of the graphics techniques 1 used in the reporting mechanism 
were previously present in my raytracer software (see % 6) . Although I showed the product to other 
people in the company and discussed features and functions with them, the design of the algorithms 
and the coding of the software was done solely by me, or by people working to implement my 
instructions. While the reporting mechanism is a good computer program, and while it provides the 
functionality to support that piece of Foundstone's business, I am unaware of any feature in that 
software package that is exclusive to Foundstone. Moreover, the Fire & Water software, to be 
released by NTO, does not include the reporting mechanism software which was created while I was 
at Foundstone. 

15. While employed by Foundstone I designed and implemented the FASL (Foundstone 
Attack Scripting Language) that I am informed and believe they are also still using as part of their 
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1 valne^ility assessment. I had previous experience writing computer languages such as the 80486 

2 assembler which I had written before I worked at Foundstone. THe graphics capabilities in that 

3 software were substantially baaed oo my raytracer software (see H 6). Although I showed the 

4 product to otherpeople in the company and discussed features and functions with them, the design 

5 of the algorithms and the coding of the software was done solely by me, or by people working to 

6 implement my instructions. While it is a good software package, and while it provides the 

7 functionalfty to support that piece of Foundstone's business, I am unaware of any feature in that 

8 software package mat is exclusive to Foundstone. Moreover, me Fire & Water software, to be 
9 1 released by NTO, does not include anything like FASL. 

10 ITOTTT^STONE'S^ JJEG^ 

11 16. I have read the Declaration of Stuart McClure submitted in support of this OSC re 

12 Preliminary function. From review of that doeument I am unable to determine any specific 

13 method, algorithm or technique which is being referred to by Foundstone as a trade secret. 

14 17 To the extent that I am generally familiar with the graphical techniques which exist 

15 inthe Foundstone soft^^ 

16 it is my testimony that all of the graphical techniques that Foundstone may be clamung as 

17 proprietaryaredocumentedmpublicdomainmaterials. Specifically, to my recollection, they can 

18 all be found in a book called "Computer Graphics Principles and Practice" by Foley, VanDam, 

19 Feiner and Hughes. 

20 18 I.te a »nWI■F>^l^* to,l- ^ , ^ , ** 

21 exist in the Foundstone software, because they exist in software I worked on while I was at 

22 Foundstone, it is my testimony mat * of me mathematical techniques that Foundstone My be 

24 book Tne cubic spline interpolation was done by copying code samples in a book called 

25 "Numerical Recipes" by William H. Press, Brian P: Flannery, Saul A. Tenkolsky and William T. 

26 Vetterling. 

. - - ir^Tm^Qirm that Foundstone might be claiming 

27 19. The McClure declaration gives the impression tnat ru 

, • , j« i „ fh* wnrld wide web are mostly HTML. All 

28 HTMLasatradesecretThepageswhichdisplayontheworldwiae 
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of the HTML techniques that I used atFoundstone were standard. No new ground was broken there 
All of the HTML I have done at NTO is, likewise, standard programming techniques. 

ireCfSION TO LEAVE 1TOTTNDSTQ NF- AND JOIN NTQ 

20. JD Glaser and I became friends while we were both working at Foundstone. Prior to 
giving notice at Foundstone I asked JD whether I could work for his company. He advised me that 
under his Employment Agreement with Foundstone he could not have any such discussion ™th me 
while I was working for Foundstone. 

21. Therefore, I gave my two week notice to Foundstone. My last day with Foundstone 

was June 28, 2002. 

22. 1 subsequently applied for a job with NTO. I am presently the Senior Software 



11 1 Engineer for NTO. 

12 1 23. We have, as a result of this litigation, been required to spend time meeting with our 

13 legal counsel. Based on those discussions, and based on my discussions with the other employees 

14 of NTO, and based on my knowledge of computer programming and computer techniques, neither 

15 I, nor any other person at NTO, is utilizing anything which I understand to constitute a trade secret 

16 of Foundstone in the furtherance of the business of NTO. 

17 1 I declare, under penalty of -perjury, that the foregoing is true and correct and that this 

18 declaration is executed on October 23, 2002, under the laws of theState of California, 

19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
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Steven Brower, State Bar#93568 

i^^r^G^R KKHMAN & THEODORA 

A Professional Corporation 
535 Anton Boulevard, Suite 800 
Costa Mesa, California 92626 
Telephone: (714)241-0420 

Attorneys for Defendants 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONE,INC., 
Plaintiff, 

vs. 

NT OBJECTIVES, INC., et al., 
Defendants. 



CASE NO: 02CC15350 
Judge David H. Brickner 
Dept. C17 

DECLARATION OF ERIK CASO TN 
OPPOSITION TO OSC RE: 
PRELIMINARY INJUNCTION 

Date: October 25, 2002 

Time: 3:00 p.m. 

Dept: C17 



I, Erik Caso, declare: 

1. The facts stated herein are of my own personal knowledge except for those set forth 
on information and belief, and as to any such facts, I have a basis for believing that Ihey are true. 
If called upon to testify as a witness I could and would competently do so as set forth herein, 

RQLE IN THf « I.rWCATlON 

2 T am individuaUy named as a defendant in this matter. 

3. Iwas employedby PlaintiffFoundstone, Inc. &om May 2001 until June 2002, as more 
fully set forth below. I was never an officer or director of that company. 
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ij "R A CTfCQROT J ND XS COMPUTER BUSINESS. 

2 4. I obtained my bachelors degree in Business from California Polytechnic State 

3 University, San Luis Obisbo in June, 1997. My coursework included web design/authoring and 
4 1 using complex modeling software to create statistical forecasting models. 
5 1 5. From April 1998 to March 2000, 1 was employed by The Boeing Company as a 

6 Business Analyst, using software for financial modeling of return on investment and other business 

7 planning. 

8 6. From March 2000 to February 2001, 1 was employed by Epoch Internet as a Product 
9 1 Manager. I designed software based products for a large Internet Service Provider (ISP) including 

10 1 email system and real-time provisioning systems for an online portal. 
n T/MfPLOYMEN T ttV "FOTTNDSTONE 

12 7. A colleague of mine from a prior job referred me to Foundstone; I liked the idea of 

13 working for a small company which was known for doing good work. 

14 8. I began to work for Foundstone on or about May 15, 2001. My title was Product 

15 Manager. My supervisor was Dave Cole, although I primarily reported to Stuart McClure. 

16 9. I was involved in the design and execution of the FoundScan technology- That is, I 

17 worked on deciding what features should be included in the Foundscan software in order to provide 

18 mefeatureswmchFomdstonecUentseimerrequest^ 

19 customer demand for Foundstone services. I was also responsible for Foundstone's beta testing 

20 software program, sales assistance, development of marketing related materials, ensuring Quality 

21 Assurance for software, and overall management of FoundScan related objectives. 

22 10. My job responsibilities at Foundstone did not include any computer prognmirning. 

23 Although I have worked with computer companies I have not actually done any computer 

24 programming. 

25 11. Iwasnevaaskedtopartiripate^ 

26 I was at Foundstone. I have never been advised that I am named as the "inventor" on any patent 

27 application filed by Foundstone. 

28 | ^nqrettFNTTA TTNG NTO AND FOUNPSIQHE 
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12. As the person responsible for Hie overall business strategy of NTO I have been asked 
to explain the difference between Foundstone and NTO. Attached hereto as Exhibit "A," and 
incorporated herein by reference, is a document I prepared that provides a detailed description of 
the features and functions which. will be included in the "Fire & Water" tools which NTO intends 
to distribute. Attached hereto as Exhibit "B," and incorporated herein by reference, is a document 
I prepared that provides my description of Foundscan, the software package utilized by plaintiff. 
As will be readily apparent, it is materially different from anything being done by the -Fire & 
Water" tool kit Attached hereto as Exhibit "C," and incorporated herein by reference, is a 
comparison chart which I prepared showing features of FoundScan in comparison with mose in the 
Tire & Water" package. That document also shows features that are present in other software 
programs produced by entities who are not parties to this litigation. 

irmTNTOSTOTSnF'S ATJ/KGED XB AP F. SECRETS 

13. I have read the Declaration of Stuart McClure submitted in support of this OSC re 
Preliminary Injunction. From review of that document I am unable to determine any specific 
method, algorithm or technique which is being referred to by Foundstone as a trade secret 

14. Although they are not clearly identified by the MeClure Declaration, there are two 
databases which I believe might constitute the type of proprietary information to which Stuart 
McClure intends to refer. One of those might be referred to as the OS Fingerprint file. Thiswould 
be the collection of information which is used by Foundstone to do Operating System identification. 
While I am informed that the technique of OS identification is not proprietary to Foundstone, then- 
database of this information is extensive and might normally qualify as proprietary. The second 
would be the database of vulnerabilities. I am told that such a listing is actually a matter of public 
knowledge, but I believe this is something to which Stuart McClure was referring in this 
Declaration. 

1 5 These two databases (OS Fingerprint and VulnerabUities) are part of the FoundScan 
suite of security program, IXaing me tm,e mat I was employed by Foundstone, me OS Fm^^ 
database was mabtained in an "unencrypted" form. That is, anyone who had access to me computer I 
program could read and/or print the entire contents of the OS Fingerprint database. 
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1 16. As a regular part of my job at Foundstone, I was involved in sending "evaluation 

2 copies" of our software to the trade press so that they would review our products and provide us with 

3 coverage. When dealing with the press there are never any confidentiality agreements requested or 

4 obtained because the very purpose of sending the copies to the press is so thatthey will makepublic 

5 comments about your services and software. 

6 17- I specifically recall that copies of the Foundstone software (and, therefore, full ability 

7 to view and/or print the contents of the databases) was provided to: J ohn Taschek and Jim Rapoza 

8 of eWeekLabs; Andrew Conry-Murray of Network Magazine; Jane Parkhouse of SC Magazine; 

9 Mandy Andress of InforWorld; and, Konstantinos Karagiannis of PC Magazine. Each of those 

10 people, and iheir publications, had full and unfettered ability to view and/or print me entire contents 

11 of the Foundstone OS Fingerprint database. 

12 18. Notwithstanding the potential public disclosure of this database, I want to be sure it 

13 is clear thatNTO is not including any OS Identification in the "Fire & Water" package. Moreover, 

14 NTO does nol have any copy of the Foundscan OS Identification database. 

15 pFCISTON TO I.F.AVE FOT TNTESTOINTE AND JOIN NTQ 

16 19. I left Foundstone because of its lack of interest in employee satisfaction and poor 

17 management When I advised Dave Cole and Stuart McClure that I was quitting they asked if there 

18 was any job at the company, which they could give me, which would make me stay. When I turned 

19 them down they told me that I could return to Foundstone at any time in the future. 

20 20. I began to look for a new job about a month before I left Foundstone! This was about 

21 a month after JD Glaser left Foundstone. I contacted him to see what he was doing since we had 

22 been friends while he was working for Foundstone. As a business person, rather than a technical 

23 person, I told him that I had some ideas about how to structure a successful organization. 

24 21. I subsequently joined NTO where I am presently the Director, Product Strategy. My 

25 role is to develop and implement our overall product and business strategy. 

26 • 22. We have, as a result of this litigation, been required to spend time meeting with our 

27 legal counsel. Based on those discussions, and based on my discussions with the other employees 
28 1 of NTO, and based on my knowledge of computer progranmring and computer techniques, neither 
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I, nor any oHier person at NTO, is utilizing anything which I understand to constitute a trade secret 
of Foundstone in the furtherance of the business of NTO. 

I declare, under penalty of perjury, that the foregoing is true and correct and that this 
declaration is executed on October 23, 2002, under the laws^f the State of California. 




D:Wp<iocs\sbl02212.02 



-d 6OZ/H0 d 611-1 



DECLARATION OF ERIK CASO IN OPPOSITION TO OSC BE: PI 

Zmmmi jeag^uoa | q • sueu BH'eqqouM-iuo J j w^so PO-OE-90 



O O 



EXHIBIT 'B' 

898-d 602/510 d 611-1 20560926^6 1 Jeafiuuosio'sueiien'aqqouji-iuoj j uJd 0 2:Q0 fQ-0£-90 



• o o 



What is FoundScan? net work based "Vulnerability Management' 

£ ™n , distributed system »h«r« various servers srs in separate. 

SployS: r.i.i~s . FoandScao Consultant to bo onsito 

Si„. U i,'SStr«T^ ot£r tbird P-y^»-«« ts t" . 

maintained in order to operate *"^ ly ' * h %Vr To ensure proper 
SUSLtiSrSSS. £ -=« a in «an system or . they wil! 
S^cn^r^f^xes or the. ^oundScan Enterprise voidability . 
Management System-: ldentifieS , enumerates and classifies each 

' Srr.nSrt. Massif lotion can include the operating 
sysLm o^n Ports, banners, hostname, and even device type (i.e. 
S , firewalls, servers -and 802,11 wireless devices ) 
. vulnerability Engine - include. ^ -In^iUty ch^s tha 

=St^« S . 

checks are preformed using a scriptmy , % 

house! called FASL (FoundScan Attack Scrxpting Language) - 

ssks. :rr.A -s™ £Er «s. -ss 

types include Administrator, Full and View »sers. J . e | ort5/ 

. £2£5L E „,ine - o^ddod in tb. «sb portal, 

»an»g«asnt eomponont. dobbed vuMTr* k, «« ^ i]tl „ „ , 

„aaa,s«mt ot vulnerabilities dlsonv.rea J* kdjainistrator to 

sr»r saw -sj^ssl"*™-* « - a « 

Administrator for archiving. sl „: ino iDefense 

. Numerous ancillary features, "jS more 

security reports (provided by a third pa ty - ^USrise security 
F oundScan is designed, marketed and sold as « ^"^£ r network . It 
solution used to identify ^^S^ non-recurring projects 

. is not currently designed to handle numerou^ , g mnch 

related to network management as the in ^ s ^ istratOK that needs to 
greater than the resulting output an . Jd not use Foun dScan 

create and run numerous discreet network tests ^ 
due to the amount of ti- it ^ takes to log into^ ^ 
proper scan(s), run them, log into * * 
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scan view the information and then act.) FoundScan is designed to run 
S a network service, where an administrator create* 
assessment scans, or jobs, which are run on a schedule. These aobs are 
then renewed on a recusing basis and used to determine the security 
postura l an organization or network Each job is configured to be 
automatically distributed to unlimited individuals, 

ihey have access to the job or not. FoundScan may be purchased as a 
licensed technology or a managed service. 
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Feature comparison for Fire & Water and FoundSean 

dboveTeneral descriptions of each product attest to yearly 
SdicSe thf intended design of each product. With that <=°^d e red, 
Sete are several^ features and capabilities common to both 
Scnnologlts, as well as many other competing technologies offered by 
other Kre vendors. While these features/capab^txes may be 

S, Ule-ntaSons andVriatio/s of these features/capabilities 
roav be readily found in numerous software products and have been 
SELSLs f^nd available in public forums long before the founding of 
either 3 tu^to^e ' "founded Lte 1999) or *T OBJSCTivss (founded «*■ 
"1997) . 

For a feature breakdown please see the Fire s Water - FoundScan Feature 
Comparison document. 
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EIRE'&iWATER FQEINDSCiftM FEATURE ^^ P | ^^| t *^_ 



FEATURE _ 

General Assessment 
TCP port scanning 
UDP port scanning 
Banner grabbing 
Service enumeration 
Operating system Identification 
Hostname resolution 
I CMP tracerouting 
TCP traceroutlng 
Firewall detection 
Router detection 
Database detection 
Wireless device detection 

Genoral Defense 

ISAPI inter . 

Attack signature recugritiorv-bassd web server defense 

(vulnerability Checking 
Network level checks 
Operating system checks 
Remote windows registry checks 
Web server checks 
[Web] application checks 
Wirelass device checks 
Vulnerability risk rating 

Custom Scripting language for vulnerability checks 
Interpreter for parsfog and executing the scripting language 

[Data Storage 

Enterprise database usage (MS SQL) 
Data Encryption 

Segregation of data by customer 
Segregation of data by user account 

lOnllne Data Presentation and Management 
Web based portal with access control 
Online account management 

Integrated remediation managementtoorkflow system (VutnTrak), 
Query based data searching (database) 
Scan scheduler 

Automated scan instantiation (starts scans) 
Automated/configurable web based alerting 
AutornetecVconfigurabte email Alerting 
Mum-tier account creation for granular access control 
Interface for com plate system management 
Secure communicarJon over SSL (encrypted traffic) 
Includes third party security Intelligence reports 

[Reporting 

Summary level reporting 
Detailed reporting on a feature basis 
Network mapping - host level 
Network mapping - firewall levet 
Network mapping - rooter level 
Network mapping - dual homed devices 
Data trending (plot historic data points on graph) 

J Miscellaneous 

Runs only from the command line (i.e, the *C'A> prompt) 



YES 
NO 
YES 
NO 
NO 
YES 
YES 
NO 
NO 
NO 
NO 
NO 



YES 
YES 



NO 
NO 
NO 
YES 
NO 
NO 
NO 
NO 
NO 



NO 
NO 
NO 
NO 



NO 
NO 
NO 
NO 
NO 
NO 
NO 
NO 
NO 
NO 
NO 
NO 



YES 
NO 
YES 
NO 
NO 
NO 
YES 



YES 



YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 



NO 
NO 



YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 



YES 
YES 
YES 
YES 



YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 



YES 
YES 
YES 
YES 
YES 
YES 
YES 



EXISTING TOOLS DOING SAME THING 

nmep, supers can, and numerous others 
nmap. superscan, and numerous others 
nmap, superscan, and numerous others 
nmep 

nmep, xprobo, Queso' 
nmep.nstookup, numerous others 
traceroute. visualroute. Cheops 
firewalk, LAN Mac-Shot 
cheops* LAN MapShot 

ISS, nessus, LAN MapShot, InFlow, many mare 
AppDetective, ISS 
ISS, nossus 



URLScan 
Snort 



nessus. ISS, cybercop. whisker, retina + more 
nessus, ISS, eybercop, many more 
nessus. ISS, eybercop. many more 
nessus. ISS. eybercop, whisker, retina 
owasp tools, WherEonal, whiskar. retina 
nessus, ISS 

nessus, CyberCop. ISS, Shadow, many more 
nessus (nasi) 
(nasi) 



NO 



Retina. ISS, many more 
Retina, ISS, many more 

Retina 

ISS, Retina. CyberCop, Shadow, many more 



ISS. CyberCop. nessus. many other 

etaops, CyberCop, LAN MapShot, InFlow. many more 
cheops, LAN MapShot. InFlow, many more 
Cheops, LAN MapShot. InFlow, many more 
Cheops, LAN MapShot. InFlow, many more 



nessus, nmap 
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Runs asa network service 

Distributed system- multiple servers geographically rosea 
Able to run numerous simultaneous scans 
Security scoring to indicate risk posture 
Available as a managed service 
Available as software 

No installation required. Just copy files to desired directory 
Requires a trained consultant tor configuration end Installation 
Requires system management to ensure operation 
Auto-update feature to auto download system updates 
Requires third party enterprise software to operate 

Marketing & Sales 
Target market 



Price 



NO 


YES 


ISS 


NO 


YES 


1SS 


NO 


YES 


ISS. CyberCop, many more 


NO 


YES 




NO 


YES 


tss 


ves 


YES 


AH 


YES 


NO 


nmep 


NO 


YES 




NO 


YES 


ISS. CyberCop. Retina, many 


NO 


YES 


NO 


YES 





Security and 
systems 
administration 
professionals 
looking tor 
lightweight 
toote-to perform 
discrete tasks 
(such as rinding 
web servers). 



Free, or single 
user license 
may be 
purchased for 
$150- 



Large 
enterprises 
that require 
comprchonsiv 
e -Vulnerability 
management" 
solution. 



published 
pricing begins 
at $30,000. 
Individual 
sates generally 
run $100,000' 
700.000 for 
technology 
licensing. 



♦NOTE - This feature list comprises aP known FoundScan and Fire & Water features 
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Steven Brower, State Bar #93568 

Brian Barrow, State Bar # 177906 ^ a 

STEPHAN, ORINGHER RICHMAN & THEODORA 
A Professional Corporation 
535 Anton Boulevard, Suite 800 
Costa Mesa, California 92626 
Telephone: (714) 241-0420 

Attorneys for Defendants 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONE, INC., ) CASEN^CCIS^O 

Plaintiff, ) Dept. C17 



vs. 



DECLARATION OF JASSEND. ^ 

GLASER IN OPPOSITION TO OSC RE: 
NT OBJECTIVES, INC., et al., ) PRELIMINARY INJUNCTION 

Defendants. ) Date: ° c * he L 25 > 2002 

Time: 3:00 p.m. 

Dept: C17 



I, Jassen D. Glaser, declare: 

1. I am a defendant in this action. The facts stated herein are of my own personal 

knowledge except for those set forth on information and belief, and as to any such facts, I have a 
basis for believing that they are true. If called upon to testify as a witness I could and would 

competently do so as set forth herein. 

K QTE IN THIS LITIGATI ON. 

2. I am individually named as a defendant in this matter. I am also the president, director 
and majority shareholder of defendant NT Objectives, Inc. ("NTO"). 

3. I was previously employed by Plaintiff Foundstone, Inc. for approximately two years 
as more folly outlined below. I was never an officer or director of Foundstone. That is, while my 
title was "Director of Engineering" I was never a director in the legal sense of service on the Board 
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mo. I told him that I wanted to develop one of the products which I had previously sold to 
Foundstone, VisualLast, which Foundstone was obligated to return to me under oral agreement. I 
even asked him to invest $250,000 in NTO. In fact, I have several emails from Jeanne Miller- 
Romero, the inhouse legal counsel at Foundstone, as late as 3 months after I resigned from 
Foundstone, saying that she is working on getting an agreement approved to return that software to 
me. However, I ultimately realized that Foundstone was not going to proceed with the oral 
agreement. 

T?niTimSTONF'S ALLEGED TRADE SECR ETS 

26. I have read the Declaration of Stuart McClure submitted in support of this OSC re: 
10 Preliminary Injunction. From review of that document I am . unable to determine any specific 

method, algorithm or technique which is being referred to by Foundstone as a trade secret. 

27 . As stated above, the work which I did while I was employed by Foundstone was good 
progranumng, but the methods, techniques and algorithms which I used were Hie same as those I 
would expect would be used by any other excellent experienced programmer. 

28. The McClure declaration tries to give the impression that there are real technology 
secrets at Foundstone. I would, almost without exception, disagree, as more fully set forth below. 

29. As differentiated from the technical area, I would agree that Foundstone probably has 
legitimate trade secrets regarding certain aspects of their customer relationships, their pricing 
strategy, and their financial affairs. However, those items are simply not implicated here. We are 
offering a different product and/or service to a different market. Foundstone's minimum service 
packages are over $30,000 and it was my impression that they really were not interested in packages 
of less than $50,000. NTO*s Tire & Water" package is free to individuals and $125 for 
organizations. It is notjust a matter of degree. We do goffer a service which replaces the service 
Offered by Foundstone. While we would be willing to do business with the same companies which 
are customers of Foundstone, any resulting business we received would be in addition to, not instead 
of any service which those companies were obtaining from Foundstone. 

30. A simple example might help to explain the material difference between the business 
ofFomdstoneandthebusinessofNTO. The tools whid^OTO intends to provide as part of Tire & 
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Water" are solely for stand-along use. In contrast, none of Foundscan can be used wiihout 
connecting the software to an Enterprise SQL database (a separate special purpose computer with 

3 special purpose software). 

4 31. Foundstone does have real competitors. Those companies would include Qualys, 

5 Guardent and Vigilante. Some of those companies are mnch larger than Foundstone and claim to 

6 offer many more capabilities than Foundstone. Those companies already claim to have the 
technology and the ability to do what is done by Foundstone. To the extent.they do not have such 
capabilities it is because they have not undertaken the expense or the effort to write the software, 
but it is not because there are "secrets" that they don't know or can't obtain from public sources. 

32. We have, as a result of mis litigation, been required to spend time meeting with our 
legal counsel. Based on those discussions, and based on my discussions with the other employees 
of NTO, and based on my knowledge of computer programming and computer techniques, neither 
I, nor any other person at NTO, is utilizing anything which I understand to constitute a trade secret 
of Foundstone in the furtherance of the business of NTO. 

33. For every technology employed by Foundstone I can find and reference a pre-existing 
public source for that technology. This would specifically include, but not be limited to, clear 
instruction on how to do network topology maps. To the best of my knowledge, during the time I 
was employed by Foundstone we didn't invent any new algorithms or technological advancements 

mrciSION TO t it a w. FOUNPSTOm 

34. After almost two years at Foundstone I realized that I did not have any real future or 
potential for advancement at Foundstone. 1 decided to resume working for myself at NTO, I 

_ advised Stuart McClurethatl would be resigning. My last day at Foundstone was May 3, 2002. 

23 I In feet, onthatdate,I-gave»abtandnew software tool to Foundstone as a departing present. Iam 

24 informed and believe that the software tool has been utilized by Foundstone to enhance its 
25 1 marketing efforts and is currently downloadable from their website. 

35 I am aware that under my employment agreement with Foundstone I am not allowed 
to solicit any Foundstone employee to work for NTO. Whether or not such term is legally valid I 
have fully complied with the spirit of the requirement. I have never contacted any employee of 
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Foundstone to suggest that they work for me and/or NTO. However, our software development 
group was relatively small and I was friends with many people at the company. When people who 
are employees of Foundstone have contacted me to find out whether they can work for NTOI have 
reminded them of the non-solicitation clause and I have told them that 1 can't make any agreements 
with Hiem while they are employees of Fpundstone. 

A TimTTONAt, T TF.MS OF TNFCMM ATTQN 
36. The Declaration of Stuart McClure (f 30-32) refers to a presentation which I made at 
the Black Hat conference on July 29, 2002. It is phrased in a strange way because Mr. McClure was 
not actually there during my presentation. He is just reporting what he was told by someone else. 
1W II Significantly, the presentations, including the one I gave with Michael Morton, are videotaped. 

11 AftertmsHtigationsta*^ 

12 available for review, by the Court, upon request. Within the past week I have reviewed everything 
13 1 whichwassaidby me, and by Mr. Morton, on that videotape. There is nothing which we said vvhtch 

reveals or refers to any trade secrets of Foundstone. 

37 In the interest of clarity, I will address one specific hearsay statement by Mr. McClure. 
Hesaysinhis Declaration flj 31) that one of the functions demonstrated at the Black Hat conference, 
which "mimicked the proprietary functions- of FoundScan was Vdetenrdning and graphxcally 
mapping a computer network in a manner nearly identical to FoundScan." Attached hereto as 
Exhibit «D« is the graphical mapping of a computer network as performed by FoundScan. This 
' example is mtention^ Attached hereto as 

Exhibit "E" is the version which is posted on the NTO website and which was shown at the Black 

Hat conference which Mr. McClure describes. 

38 IntheDeclaraticaofStuartMcClureClS^hcsaysthatitwouldtovcbeeotapossible 

for us to create the Fire & Water toolkit in faee months. I would note the foUowing. First, while 
w announcedthe<ool»dt at nra.hme.it dearly wasn't fimshed It was more to two months later 
<« we first said wewomdbereadymmakema.tc.lavadable.Seconti.whaelwasatFoundscan 
, saw a PowerPoint presentation, done by Mr. McCnre, which showed that my development teams 
we capable of preparing computer code at impressive rates, not because of any technology a, 
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1 1 Founten, butbecause of my abilities turdthose of my staff. Third, asset forth in me deepen 

2 of Michael Morton, the various graphical mapping capabilities which exist in the Foundscan 

3 software are almost exclusively the byproduct of Mr. Morton's prior work on his rayscan project 
or are otherwise disclosed in foe books to which be references. Fourth, had Mr. McCtare been 
present at the presentation he is defining to the Court he would have known that the graphical 
displays which NTO intends to distribute do wt mimick the proprietary functions of Foundscan. 

39 He Declaration of Stuart McClure makes reference to Operating System 
Identification. We have elected not to provide the court with a mountain of paper showing how 
much of the technology, generally referred to by Foundstone, is in the public domain. However, m 
the interest of clarity, attached hereto as Exhibit V is Version 2.5 of me paper "ICMP Usage in 
Scanning" by Ofir Arkin, the founder of the Sys-Security Group. Ofir Arkin does not have any 
affiliation wimFoundstone orwifoNTO. This paper, can be obtained as a free download, without 
anyregistration, payment or agreement to any conditions. Thia document discloses, to those who 

14 take foe time to understood the document, how to do what is referred to by Mr. McClure as OS 

15 Identification. I know that this document forms the basis for the OS Identification in foe FouitdScan 
product because various venuons of this document were used by my development team in order to 

implement OS Identification at Foundstone. 

40 Further atUchedheretoasExtaVtt-G-isftehomepagefromww.sys-security.com, 

foe orgamzafionoperatedby Ofir Arkin. At.be bottom offoe page it refers to Xprobe2 "an achve 
operating System fingerprinting tool with a different approach to operating system fingerprmung. 
Xprobe2 rely on fozzy signatore matching, ptobabfistic guesses, multiple matches simultoneously, 
and a * - ^ates-foa. you can download the saw^fe. for 4-. ta» 

„ , this site. We are not arguing that this is foe exact same ming as what Foundstone is offenng. In 
24 Lc^in.omeway.itmayevenbemoresophisticateduranFounda.one. Our concern is foa, when 
Foundstone claims to W OS Identification, or any of meir other afieged trade secrets, wtfoout 

we can't show ma, foe specific item: a) is not, In ft* a secre, or b) la not, to foot, used by Nf 0. 
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41. While we reserve the right to use any non-proprietary technology in the future, 
including OS Identification, it should be clearly noted that the "Fire & Water" package does not 
include any OS identification and has never been intended toinclude such capability. 

I declare, under penalty of perjury, that the foregoing is true and correct and that this 
declaration is executed on October 23, 2002, under the laws of the State of California. 
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Steven Brower (State Bar No. 93568) 
Brian P. Barrow (State Bar No. 177906) „ _ . _ „ 
STEPHAN, ORTNGFJER, RICHMAN & THEODORA, P.O. 
535 Anton Boulevard, Suite 800 ' 
Costa Mesa, California 92626-1902 
Telephone (714) 241-0420 
Telecopier (714) 241-0622 

Attorneys for Defendants 
NT OBJECTIVES, INC., J.D. GLASSER, 
MICHAEL MORTON, ERIK CASO and 
DAN KUYKEND ALL 

SUPERIOR COXJRT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 

FOUNDSTONE, INC., a Delaware ) Case No. 02CC15350 

corporation ASSIGNED FOR A1X PURPOSES TO: 

PKintiff ) HONORABLE DAVID H. BRICKNER 

riamun ' \ DEPT:C17 

v ) MEMORANDUM OF POINTS AND 

NT OBJECTIVES, INC., a California ASSSSSS ffwK ffi°TO 

corporation; JJD. GLASER, an individual; \ gEFF^ANTS' OPPOSITION TO 

MICHAEL MORTON, an individual; ERIC S PLAINTIFF SOSC^. 

CASO, an individual; DAN ^ ) PRELIMINARY iinjun^aiv^ 

^SSSf^aS^^^ HEARING DATE: October 25, 2002 

1 througn :>u, inclusive. j JRAE: 3:00 p.m. 

Defendants ) DEPT: C17 

ueienoanxs. j TRIAL DATE: None 

) COMPLAINT FILED: October 2, 2002 



MFMOB ANPTTM OF POTNTS ANT) AUTHORITIES 

I. INTRODUCTION 

Plaintiff Foundstone, Inc. seeks to enjoin its former employees from releasing "Fire & 
Water Toolkit" a computer software product that Foundstone has never seen, but which 
allegedlyincorporatesmisappropriatedixade secrets. Foundstone fails to identify the supposedly 
stolen trade secrets or specify how they are supposedly being used in defendants' product, 
instead relying on an allegation that defendants could only have developed then product by 
virtue of their prior employment at Foundstone. 
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1 allegation its "algorithms, methods, and databases" are trade secrets thus does not describe 

2 which, if any, of the components of "Fire and Water Toolkit" were supposedly misappropriated 

3 from Foundstone. Without such descriptive information, Foundstone fails to demonstrate any 

4 likelihood of success on the merits or make any showing of relative interim harm. 

5 3. Foundstone Also Refuses To Provide Further Specificity Of Its Alleged 

6 Trade Secrets As Required By the Discovery Act. 

7 Code of Civil Procedure section 20 19, subdivision (d), states the following with regard 

8 to identification of trade secrets prior commencing discovery: 

9 In any action alleging the misappropriation of a trade secret . . . , before 

10 commencing discovery relating to the trade secret, die party alleging the 

11 misappropriation shall identify the trade secret with reasonable particularity 

12 subject to any orders that may be. appropriate under [the Uniform Trade Secret 

13 Act]. 

14 Defendants have repeatedly asked Foundstone for such an identification, specifically 

15 explaining that Foundstone's pleadings contain an insufficient description of the alleged trade 

16 secrets. Tellingly, Foundstone has so far refused to provide defendants with the requested 

17 specificity, despite previously seeking leave to commence ihe discovery process. 

18 D Foundstone's "Software, Methods, and Algorithms" Are Not Protectible 

19 Trade Secrets. 

20 Even if the generic "software, methods, and algorithms" is considered a sufficient 

21 description of a trade secret, Foundstone nevertheless fails to provide evidence demonstrating 

22 that such material is entitled to trade secret protection. Foundstone thus fails to show mat its 

23 claimed "software, methods, and algorithms" are actually trade secrets. 

24 "The test for trade secrets is whether the matter sought to be protected is information (1) 

25 whichis valuable becau^^^ 

26 secret " (Schlage Lock Company v. Whyte (2002) 101 Cal.App.4th 1443, 1453, citing Abba 

27 Rubber Co. v. Seaauist (1991) 235 Cal.App.3d 1, 18.) Foundstone offers no evidence satisfying 

28 either of these requirements. 
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L FoundsWsAUegedTradeSecretsandSoftwareProductsAreBased 
on Information Avattable In the Public Domain. 

TTie United States Supreme Court has stated that information that is public knowledge or 
that is generally known in an industry cannot be a trade secret {Ruckelshaus v. Monsanto Co. 

(1984) 467 U.S. 986, 1002.) 

As shown in the Declarations submitted in Opposition, Foundstone did not actually invent 
anything. To the extent that defendants are able to identify alleged trade secrets the Declarations 
show that such materials were originally created by sources outside of Foundstone, are known 
to those who are experienced in the industry, or have been deliberately disclosed to the public 
by Foundstone. 

2- Foundstone Disclosed Any Trade Secrets Contained In Its Software 
When It Provided Unprotected Marketing Versions to the Press. 

Foundstone cannot validly claim mat its various databases upon which FoundScan 
operates have been the subject of efforts to prevent the loss of secrecy. As explained in the 
declaration of defendant Erik Caso, Foundstone repeatedly provided members of the press with 
copies of its software products that were vulnerable to disclosure. Foundstone never insisted mat 
the members of the press to whom the software was delivered execute nondisclosure agreements 
or otherwise promise not to publicize its alleged trade secrets. As such, members of the press 
who received the software were free to, even encouraged to, view the very components of the 
software (i.e. databases, etc) that Foundstone now contends are trade secrets they have attempted 
to keep confidential. Foundstone's own acts of disclosing information to outsiders demonstrates 
that the alleged trade secrets no longer enjoy the secrecy that Foundstone claims in this lawsuit 
E. Foundstone Has No Evidence of any Actual or Threatened Misappropriation 

of "Software, Methods, and Algorithms." 
This court may only enjoin "actual or threatened misappropriation" of a trade secret 
26 I (Civ Code, § 3426.1, subd. (a).) "Misappropriation'' is defined in this context as improper 
acquisition of aftadesecret or its nonconsensual use or disclosure. (Civ. Code, § 3426.1, subd. 
00 ) Foundstone is therefore burdened with making a showing that defendants are erther 
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Welcome to the Kuykendatl Website. 

Hello r I am Dan Kuykendatl ( aka Seek3r ). Welcome to my website. This site Is 
mended to be for the use of the visitors and myself to discuss whatever Issues are on 
our minds, 

^ ^e gal Docs: The response to thgiir^mplqinl; 

In itife article on ftal>corn there Is a great ©ample of what Foundstone 
1$ doing: * 

■Finally, thereto Muffing. Trtts happens, all the time. During the 1992 
presidential campaign, Ross Perot copyrighted Ws Dteness and 
convinced Dana Carvey to stop parodying him on Saturday Night live, 
despite the feet that parody explldtty falls under "fair use* and they 
had been parodying other copyrighted and trademarked properties 
(such as Eddie Murphy doing "Gumby" and "Buckwheat?) for years. The important 
thing wasn't whether Perot had a case that would hold up m court that he had 
a lot of money to spend on lawyers, he sounded serious, and that Dana Carvey 
backed down/ 1 

The fact Is that we have done nothing wrong,, but they "have money and act serious 
to Intimidate us. The problem for them Is— we are not Intimidated! 

Here Is the full collection of legal docs: 

The new stuff: ma 
Here are the declarations of aU the defendants m the case; JD Gteser, Mike Morton 
and myse lf. Here is our DgfgrMfr pts Menioraridu rn_0f Qr^slfeo and their foal 
reply. Now Its m the judges hands and his decision will be posted on nttweteite fc y 
4S0PM PST, Oct 25 2002. 
The old stuffs 

The Terr^ra^. Restrain and Stuart McfJure'.S Periaxawn. 

Their oomplalnt - 1-lQ / 11-20 / 21-23 and the Pfalntifts Memorandum - 1-10 / 11- 

Click the read more link for *ray* opinions on each point of Stuart's 
Declaration. 
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P Lg gal Case; Hera coJne g_lhAJg&5S 

Things are moving along with the lawsuit. Friday Is going to be the day 
%jfl that the Judge will make the decision on the Pellmlnary Injunction. If 
Bf we win; then we will be free to release our toolkit* The press has 

gotten ahold of the story as well. It has shown up on the very popular 
In^ejsii^^K and on Secujl£^mlQisJiaXQt. 

Cffck the Re&d more... linker some internal problems at Founstone, 
that stem from this case. 

posted by: seeK3r on Tuesday, October 22, 2002 - ^CgAM PST 
Rjea rj rriore... (6B1 bytes more) comments? 1^1^ 
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In thfe article on FooUom there is a great example 
of what Foundstone is doing; 
'Finally/ there's bluffing. This happens all me time. 
During the 1992 presidential campaign, Ross Perot 
copyrighted his fikeness and convinced Dana 
Carvey to stop parodying him on Saturday Night 
. Uve, despite the fact that parody explicitly fatis 
under "fair use" and they had been parodying other ■ 
copyrighted and tradenrarked properties (such/as Eddie Murphy 
doing "Gumby* and "Buckwheat?) for years* The important 
thing wasn't whether Perot had a case that would hold up in 
court that he had a lot of money to spend on lawyers, he 
sounded serious, and that Oana Carvey batted down/ 

The fact Is that we have done nothing wrong, but they have 
money and act serious to Intimidate us. The problem for them 
Is... We are not Intimidated! 

Here Is the full collection of legal docs; 
The new stuff: , 

Here are the declarations of all the defendants In the case; JD 
Giaser r Mfr fi N orton and myself. Here fe our Qeferntents 
Memorandum of Opposition and their (foal reply. Now Its in the 
judges hands and his decision will be posted cm ffe wefrsjts by 
4;30PM KT, Oct 25 2002, 
The old stuff; 

The Temporary Restraining order and Stuart Mcdure's 
pedaratton . 

Their complaint - 0=10 / U^D_ / 21-23 and the Pktntiffc 
Memorandum - J Urt6 

aide Re read more Hnfc for ♦my* opinions on each 
paint of Stuart's Declaration. 



My qutek response to ^rt MoClure's Declaration which Is the 
only actual "feds 11 they have presented to the court 
♦These are my opinions and while I believe everything I am 
Stating to be true, this not a legal rebuttal * I wlU be posting 
ail our legal nssponces as they become avaffible* 

Hrst lets I00K at what the taw considers a Trade Secret 
A gc^xpMoalleii basicly says that "A trade secret is any 
information that aHows you to make money because It Is not 
generally known". Since hacker techniques are generally Known 
and published on several websites, as welt as techniques for 
port scanning, operating system fingerprinting and visualized 
network mapping from traceroute data, they cannot dalm them 
as Trade Secrets. 

Read my responses along side of his Declaration, 

1) True enough 

2) Notice how he makes rt specific who their target 
audience/market Is- This Is not the same as 5ffl£§ which Is 
releasing small command line tools for the general network and 
security admin. 

3) No problem with this " 
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4) I question the actual coste/hours. From my calculations a 
single persons^ full time hours far a year come out to a bout 
2,000, To account for 80,000 would mean 20 people ($ lQOk 
average annual salary/cost) working on It fall time for the test 

. two years its been In development 
Doesnt seem accurate.- buttts not an Important point to the 
case... but one that he repeats several times, so I felt I should 
shoot It down up front 

5) For sure their source code, and databases are their own. 
Possibly the actual algorithm for calculating their often 
discussed "FQUndScore". Other than thatl am not personally 
aware of any other Trade Secrets that they have. 

6) He says In this that FoundScan Is the heart of Foundstone s 
business. This is does not mate sense In terms of revenue as 
far as I know* foundstone has been a very sucessful 
"Consutong and Training" company up unol their recent release 
of FoundScan. I dont see how anew product that has only sold . 
a limited number of copies has outstripped their long 
established consulting and training business, 

7) What he Is talking about Is operating system fingerprinting- 
tor "OS ldent\ This is a very common and weH understood 
process In the Industry, Yes they have their proprietary 
irnpiementatlon, but Tingerprlntmg' end "OS Idenl? (whfch we 
dont even do vet) Is certainly not some Trade Secret to 
Found stone. 

8) Again, they have their own proprietary implementation, but 
visually mapping a network based on traceroute data is well 
understood and exists In many products. In sty's own track he 
talks about Cheops which does this and has existed far longer 
than FoundScan, . 
9} Again, they have their own proprietary implementation ana 
technique for automated vulnerability testing, but as far as I 
know afl of the vulnerability checks they (and just about anyone 
dse) do are well described on sites such as Sggiri^EQCiia- 
They then display this In a spherical map which they ( have 
examples of on their own website... how he still thinks this is a 
trade secret ts a mystery to me, Regardless, this is not 
something we are even doing* 

10) Again, they have their own proprietary hT^lementotfon, but 
this Is Just talking about a web Interface to an epplcatton. u I 
had stolen their code, this Is a problem. Finally, J am not even 
doing anything even remotely slmOalr tor WTO. 

11) Again, they have their own proprietary ImpleraerrtaHoti, but 
web crawling to inventory and hack Is a wen understood and 
documented process *i the security Industry. _ 

12) Again, they have their own proprietary ki^lenrenratlon, but 
most of this is just trend reporting. Stuff that tc^ls like ■ 
Microsoft Excel and Crystal Reports have been doing tor years. 
Trending Is trending fc trending. The mentioned "scoring 
system'^ ™* 
talk about toe details of In the Hacking Exposed book andotner 
forums* But I do think toe exact algorithm Itself Is ^ecret.. 
one which I dont even know. This is also not something we are 
doing at NTO. 

13 - 17) i have no problem with these 
18) This Is not entirely true. 1 wont go Into the details... but up 
m very recently some parts were plain text* Regardless, toe 
general point Is true enough. 
19 & 20) No problem with these 
ZD This is not true. The documents I have seen from toe 



purchase do not cover NTO Scanner, so the word aft Is not 
accurate.Whats more is that scanning Is the heart of the Fire & 
Water toolkit So we already had code to work from, S dont 
know If any of toe old scanner code was accused for the 
new scanner," but we had some to use none the less* 

22&23) No problem with these a. -7 r/ 

24) This Is kind of lame and as far as Im aware toey knew F AGfc^OFT 
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'about his desire to bring MTO back to Rfe, Addittonatty NTO Is 
*not* a direct competitor to r^ndstone- We happen to be 
mother compute security tool company... but that does not 
mate us a direct competitor since we am not targeting their 
Fortune 500 market with a lite product 
25 - 30) rto problem with these 
3D He cans the 3 functions, "proprietary rundtons* which 
means that the given functionality and not Just their 
Implementation is proprietary, I am pretty sura.the only way to 
make a "function* proprietary *s to get a Patent, which they <1° 
not have and could not get because of the vast amount of prior 
art Point 1 Is Just a network map from traceroute data, as 
mentioned before. Also he calls Q^Lnm ^a^Y identical to to 
map , see tor yourself his exageratlon. Number 2 seems to 
Indicate that using a hypertext solution for reporting (aka 
HTML) is not allowed- For one, we dont even have s *fjL a 
tool,, for another we almost exduslvety use XML and X5LT tor 
all of our data and reporting, AND Its not a trade secret to use 
HTR for a report! Number 3 is again not something we even 
■ have a product to do, and its no trade secret, 

32) I take great personal issue with this. The teams 

* happeretobesomeofthebestrromthdrowndevetoprnerit 
team. I have proven to him and the entire development team 
on a couple occasions what I can accomplish In a short period 
'■ of One, I wrote theirentite web Interface to scan management 
In about 3 weeks when I first started with the company, I also 
wrote their vulntrak app fli about a month- The other 
developers at NIQ-are even probably even better programmers 
than 1 am. This is really just a personal Insult-, and Its atso not 
hue. We have produced rapidly... but even then we had Just 
barely been read/ to release the products. What we showed at 
BJackhat was demo's arid mock-ups for the most part- 

33) No problem with this 

34) This Is so fame* First the security industry has been built on 
disclosure of techniques for haddng and securing. The point 
that their Fortune 500 customers would forgo buying a $150k 
software package mat Integrates over a hunded features and 
provides enterprise scalability and management for a set of 
DOS PKOMPT/Command Une utilities Is a joke! 

35) Yes, so we are not rich :-*) I do have a problem with that-. 
butthats not an fesue for this ^ . 

36) I have made my^ase against this Igrcej2pjgt but I WW wait 
whim to^in Rinrtrifitone's Free tools and Stuarts own 
book called Hagjdng Exposed which explains In great detail the 
methods of hacking, 

37 - 39) Mo problem with these. 

In the end I hope I have explained how weak their case is. t 
will state again that *WE HAVE NtfT STOLEN THEIR COPE OR 
• ANYTHING THAT IS THUR ACTUAL TRADE SECRETS". We 
have our own Ideas, our own code and our own products, I 
Wish Fourufefcone would just leave us alone, stop bluffing and 
trying to make us bum our money on the legal costs for 
defending ourselves. I encourage anyone that wants to, to 
email them and give them your opinions (pro or con, tha,t Is 
your choice). 

I do hope you encourage them to back off and let us go about 
our business and them go back to theirs, 

Dan KuykfindaP 
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Darrell L. Olson, Bar No- 77,633 
Michael K. Friedland, Bar No. 157,217 
Douglas T* Hudson, Bar No- 210/385 
KNOBBE, MARTENS, OLSON & BEAR, LLP 
2040 Main Street 
Fourteenth Floor 
Irvine, California 92614 

(949) 760-0404 (telephone) 

(949) 760-9502 (facsimile) 

Attorneys for Plaintiff FOUNDSTONE, INC. 



. SUPERIOR COURT OF THE STATE OF CALIFORNIA 
COUNTY OF ORANGE, CENTRAL JUSTICE CENTER 



OCT 0 4 20GZ 



FOUNDSTONE, INC. 
corporation, 



a Delaware 



Plaintiff, 



v. 



NT Objectives, Inc., a 
California corporation; J.D. 
Glaser, an individual; Michael 
Morton, an individual; Eric 
Caso, an- individual; Dan 
Kuykendall, an individual; and 
DOES 1 through 50, inclusive/ 

Defendants , 



CASE NO. 02CC1530 

ASSIGNED FOR ALL PURPOSES TO: 
COMMISSIONER ELEANOR M. PALK 
DEPT. C62 

DECLARATION OF STUART MCCLtTRE 
IN SUPPORT OF PLAINTIFF' £ 
APPLICATION FOR TEMPORARY 
RESTRAINING ORDER AND 
PRELIMINARY INJUNCTION, 
REQUEST FOR EXPEDITED 
DISCOVERY* AND REQUEST FOR 
FILING UNDER SEAL 

HEARING DATE: Oct- 4, 2002 

TIME: ' 1:30 p.m. 

DEPT: C62 

TRIAL DATE; None- 

COMPLAINT FILED: Oct. 2, 2002' 



I, Stuart McClure, declare: 

1. i am the President and Chief Technology Officer of . 
Foundstone, Inc., Plaintiff in the above-titled action. I 
have served as President and Chief Technology Officer of 
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Foundstone since 1999. The following is true of my own 
personal knowledge; and if called and sworn as a witness, I 
could and would testify competently thereto. 

2. Foundstone specializes in computer network security 
and provides network security audits, education services, and 
security software for Fortune 500 companies, government 
agencies, and others worldwide* 

3. Founds tone's principal product is FoundScan, a 
unique proprietary software system that automatically scans 
computer networks, tests networks for ^hacking" 
vulnerabilities, provides detailed graphical reports and maps 
of tested networks and vulnerabilities, scores the security of 
networks, and reports on results of those tests. 

4. Over the past three years, Foundstone has invested 
more than $4 million dollars and more than 80,000 person-hourrs 
in research, development, and testing of the proprietary 
FoundScan software. 

5. Foundstone 's proprietary FoundScan software contains 
a number of well-guarded algorithms, methods and databases 
that are highly valuable trade secrets of Foundstone\ In 
particular, FoundScan contains trade secret software 
technology relating to securing corporate and government 
computer networks against hackers, cyber-terrorists> and 
electronic espionage. 

6. This trade secret technology is the heart of 
Foundstone' s business, and its value would be s ubs t ant i ally 
diminished if it were to fall into the public domain. So long 
as the technology continues to be maintained as secret, 
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competitors and potential competitors would have to invest 
similarly large amounts of time and money to develop systems 
with similar capabilities to compete. 

7 . Foundstone ' s proprietary methods and databases for 
operating system identification include- techniques for sending 
TCP (Transmission Control Protocol) and ICMP (Internet Control 
Messaging Protocol) packets to a target computer, which then 
responds with packets of its own. Based on the target 
computer's response, the operating system of the target 
computer is identified against a proprietary database. 

8. Foundstone' s proprietary methods and databases for 
determining and graphically mapping a computer network include 

13 methods for ICMP and TCP tracerouting to all devices, 

14 analyzing the results of the tracerouting to understand the 

15 J placement of those devices on the network, and then visually 
displaying those devices in a three-dimensional map- 

9. » Foundstone' s proprietary methods and databases for 
detecting network vulnerabilities and reporting them with the 
network map include methods for sending a series of packets to 
a target device to prompt a particular response. Once the 
response is collected, it is analyzed and compared to a series 
of rules that define a vulnerable device. Once identified as 
vulnerable, the device is then associated with a device 
discovered during the network mapping stage, and the result is 
displayed on the three-dimensional spherical map. 

10. Foundstone' s proprietary methods and databases for a 
remote administration web interface include methods for 
alerting a user of newly discovered vulnerabilities, 



16 
17 
18 
19 
.20 
21 
22 
23 
24 
25 
26 
27 
28 



I i _ 

898-d 602/260 d 611-1 ZQS609i6f6l jeeg 7 uos| 0 'su9iJE H 'eqqou)HJOJ d uid^igo fO-OS-90 



„tfi-99:(ss^ui) NOIlVana « 30C60»6fr6^:aiS9 » 90C6ZZ8:SINa « 0/t-JdXd3-OidSn^lAS « [auiu wGyAea tuajsegj Wd W93=6 W0&0C/9 IV OAOH , 8EZ/29 3SWd 



proprietary databases of vulnerabilities, tracking of 
discovered vulnerabilities through a workflow process of 
fixing them, displaying reports of found vulnerabilities, 
displaying threat information, displaying and controlling the 
status of scans, managing user and administrative roles within 
the web interface, and searching the proprietary database for 
relevant vulnerability information - 

11. Founds tone's proprietary web modules for 
vulnerability testing of weh servers include , methods for 
"crawling" a web site for links, inventorying the technologies 
in place, "brute forcing" authentication mechanisms to unearth 
easy-to-guess passwords, guessing the names of existing but 
not readily linked-to files, testing for poor script input 
validation, and testing for source code disclosure issues, 

12. Foundstone's proprietary methods and databases for 
reporting vulnerability results over time include methods for 
an objective security scoring mechanism, a breakdown of 
network inventory by live hosts, services open, a 
vulnerability network map, operating systems running, 
vulnerabilities found, web module analysis, and trending of 
these results over time, 

13 . Foundstone has taken extensive steps to protect the 
trade secrets contained in the FoundScan software, as is 
necessary to protect the substantial economic and competitive 
value of Foundstone's trade secrets. These secrets provide 
efficient network scanning, effective graphical mapping of 
networks and vulnerabilities on those networks, and 
understandable reports on network security. 
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14. Foundstone protects its software internally with 
passwords, ^software source safes," firewalls and other 
network security measures. 

15. Foundstone' s physical facilities axe protected by 
security measures including closed-circuit cameras, security 
badges , and biometric devices* 

16. All of Foundstone' s customers are under strict non- 
disclosure agreements and covenants not to reverse engineer 
FoundScan. Attached as Exhibit "A" to this declaration aire 
true and correct • copies of three example non- disclosure 
agreements of the type signed by Foundstone 's customers. 

17. FoundScan service customers do not have any access 
to the FoundScan software. These customers only interact with 
the software through a web interface, while the software ruins 
from computers controlled by Foundstone. 

18. The few FoundScan customers who do have access to 
the FoundScan software only have access to object code. 

19. All of Foundstone' s employees, including Defendants 
J.D. Glaser ( w Glaser w ) , .Michael Morton (^Morton"), Eric Caso 
("Caso") and Dan Kuykendall p*Kuykendall" ) , signed agreements 
recognizing the trade secret status of its software and 
research. Attached as Exhibit *B" to this declaration are 
true and correct copies -of the agreements signed by each of 
the above-named individuals. 

20* All . of Foundstone' s employees, including Defendants 
Glaser, Morton, Caso, and Kuykendall, signed non-disclosure 
a g reemeil t: S as part of their agreements promising not to 
divulge Foundstone 's trade secrets, and they stipulated and 
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Darrell L. Olson, Bar No, 77,633 
Michael K. Friedland, Bar No, 157,217 
Douglas T. Hudson, Bar No. 210,385 
KNOBBE, MARTENS , OLSON & BEAR, LLP 
2040 Main Street 
Fourteenth Floor 
Irvine, California 92614 
(949) 760-0404 (telephone) 
(949) 760-9502 (facsimile) 

Attorneys for Plaintiff FOUNDSTONE, INC. 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
COUNTY OF ORANGE/ CENTRAL JUSTICE CENTER 



FOUNDS TONE , INC., a Delaware 
corporation, 

Plaintiff, 
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California corporation ; J.D . 
Glaser, an individual,- Michael 
Morton, an individual; Eric 
Caso, an individual; Dan 
Kuykendall, an individual; and 
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Defendants . 
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ASSIGNED FOR ALL PURPOSES TO: 
COMMISSIONER ELEANOR M. PALK 
DEPT. C62 
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POINTS AND AUTHORITIES IN 
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TEMPORARY RESTRAINING ORDER, 
PRELIMINARY INJUNCTION AND 
EXPEDITED DISCOVERY 
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DEPT: C62 
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secrecy* " Vacco Industries, Inc. v. Van Den Berg , 5 Cal.App. 
4th 34, 50 [quoting Cal. Civ. Code § 3426.1(d) J. 

Misappropriation of a trade secret includes * [d] isclosure 
or use of a trade secret of another without express or implied 
consent by a person who . ♦ . (B) At the time of disclosure or 
use, knew or had reason to know that his or her knowledge of 
the trade secret was; . . . (ii) Acquired under circumstances 
giving rise to a duty to maintain its secrecy or limit its 
use; or by improper means of disclosure including breach of 
duty to maintain secrecy." PMC, Inc. v. Kadi aha , (2000) 78 
Cal.App.4th 1368, 1382-83 (quoting Cal . Civ. Code § 
3426.1(b)). Because each of these elements are met here, 
Foundstone is likely to prevail .on the merits. 

1« Foundstone Has Established the Existence of Trade 
Secrets 

The Uniform Trade Secrets Act defines a trade secret as 
^information, including a formula, pattern, compilation, 
program, device, method, or technique, or process that [] 
derives independent economic value, actual or potential, from 
not being generally known to the public or to other persons 
who can obtain economic value from its disclosure or use/ 
Cal. Civ. Code S '3426.1(d). Schlage Lock Co. v. Whyte , 2002 
Cal.'App, LEXIS 4634 f *13 (Cal. App, 4th Dist . Sept. 12, 2002) 
(affirming trade secret status of misappropriated materials) . . 

Foundstone' s technologies certainly meet this definition. 
The Foundstone technologies at issue are: 

(1) Foundstone' s proprietary methods and databases for 
operating system identification, which include techniques for 
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sending TCP (Transmission Control Protocol) and ICMP (Internet 
Control Messaging Protocol) packets to a target computer, 
which then responds with packets of its own. Based on the 
target computer's response , the operating system of the target 
computer is identified against a proprietary database of over 
eight hundred operating system *f ingerprints . " (McClure 

(2) Foundstone's proprietary methods and databases for 
determining and graphically mapping a computer network, which 
include ICMP and TCP tracerouting to all devices, analyzing 
the results of the tracerouting to understand the placement of 
those devices on the network and then visually displaying 
those devices in a three-dimensional map. (Id, r 118.) 

(3) Foundstone's proprietary methods and databases for 
detecting network vulnerabilities and reporting them with the 
network map, which include sending a series of packets to a 
target device to prompt a particular response. Once the 
response is collected, it is analyzed and compared to a series 
of rules which define a vulnerable device. Once identified as. 
vulnerable, the device is then associated with a device 
discovered during the network mapping stage, and the result is 
displayed on the three-: dimensional spherical map, (Id. , 119.) 

(4) Foundstone's proprietary methods and databases for a 
remote administration web interface/ which include alerting a 
user of newly- discovered vulnerabilities, proprietary 
databases of vulnerabilities, tracking of discovered 
vulnerabilities through a workflow process of fixing them, 
displaying reports of found vulnerabilities, displaying threat 
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information; displaying and controlling the statue of scans r 
managing user and administrative, roles within the web 
interface, and searching the proprietary database for relevant 
vulnerability information* (Id.,. IflO.) 

(5) Foundstone' s proprietary web modules for 
vulnerability testing of web servers, which include ^crawling" 
a web site for links, inventorying the technologies in place, 
^brute forcing" authentication mechanisms to unearth easy-to- 
guess passwords, guessing the names of existing but not 
readily linked- to files, testing for poor script input 
validation, and testing for source code disclosure* (Id., 
1T11-) 

(6) Foundstone's proprietary methods and databases for 
reporting vulnerability results over time including an 
objective security scoring mechanism, a breakdown of network 
inventory by live hosts, services - open, a vulnerability 
network map. operating systems running, vulnerabilities found, 
web module analysis, and trending of these results over time- 
(Id., H12.) 

These technologies are not generally known to the public 
or to those who could obtain economic value from their 
disclosure or use. As discussed above, Foundstone created 
these technologies only through investing 80,000 person-hours 
and $4,000,000 of research and development. (Id., U4 . ) 

These technologies also derive value from their secrecy. 
The resulting technologies are valuable to Foundstone only 
because - and only for so long as - the technologies are 
secret. (Id., 16.) Foundstone is able to market its software 
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1 and ^services effectively because it offers a product that is 

2 unique. (Id., U3.) So long as the technologies continue to 

3 be maintained aa secrets, competitors and potential 

4 competitors would have to invest similar large amounts of time 

5 and money to develop systems with aimilar capabilities to 
6T compete with Foundstone. (Id., fS.j If the technologies were 

7 to be disclosed, entities could compete with Foundstone 

8 without having to make these investments, thereby devastating 
J the market position Foundstone established as a result of its 

10 huge research and development investment. (Id.) 

11 2- Foundstone Has Taken Far-Reach ing Steps to Protect 

12 9 the Secrecy of its Technologies 

13 As described above, Foundstone has taken extensive steps 

14 to protect the confidential status of its trade secrets. 

15 Foundstone protects its software internally with 

16 passwords, firewalls, -software source safes," and other 

17 network security measures. (Id.. UUl3 -14.) Foundstone 
lJ physical facilities are protected by security measures 

19 including "biometric" security devices. (Id., U15) 

20 All of Foundstone' s customers are under strict non- 
21 disclosure agreements and covenants not to reverse engineer. 

22 (Id-, 1116 & Ex. A) Foundstone' s service customers do not have 

23 any access to the Foundstone' s software. These customers only 

24 interact with the' software through a web interface while the 

25 software runs on computers controlled by Foundstone. (Id., 

26 H16.)' The few Foundstone customers who have access to 

27 Foundstone' s software only see object code. (Id., 117). 

J All of Foundstone' s employees, including the individual 
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1 Defendants, signed agreements recognizing the trade secret 

2 status of Foundstone' s software and research. (Id., U19-20 & 

3 Ex. B.) In addition, all o£ Poundstone's employees, including 
4- - the individual Defendants, signed non-disclosure agreements 

5 promising not to divulge Foundstone' s trade secrets. (Id.) 

6 3- Defendants Indisputably Had Access to Foundstone* s 

7 Trade Secrets 

8 There can be no dispute that Defendants had access to 

9 Foundstone' s trade secrets. Each of the individual Defendants 
10 was employed by Foundstone and, while at Foundstone, had key 
22 roles in developing the trade secret technologies that are at 

12 issue in this Motion. (Id., 1129.) Defendant NTO was founded 

13 by and consists of the individual Defendants. (Id.) 

14 4. Defendants * Release of Their Software -Would Breach 

15 Their Duties to Maintain Secrecy 

16 Each of the individual Defendants executed employment 

27 agreements that included comprehensive nondisclosure 

28 provisions. {Id., Hi 9 & Ex. B.) By releasing software 

19 containing Foundstone' s trade secret technologies, Defendants 

20 would certainly be breaching their obligations of 

21 confidentiality pursuant to their agreements with Foundstone. 

22 Because the evidence establishes both that the balance of 

23 the hardships weighs dramatically in favor of Foundstone and 

24 that Foundstone is likely to prevail on the merits, this Court 

25 should temporarily restrain and preliminarily enjoin 

26 Defendants from using or disclosing Foundstone 's trade 

27 secrets. Vacco Industries, Int^ , 5 Cal . App. 4th 34, 53-54 ; 

28 Merrill Lynch , 2001 U.S. Dist. LEXIS at *14-*17. 
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Darrell L. Olson, Bar No. 77,633 
Michael K. Friedland, Bar No* 157,217 
Douglas T. Hudson, Bar No. 210,385 
KNQBBE, MARTENS, OLSON & BEAR, LLP 
2 040 Main Street 
Fourteenth Floor 
Irvine, California .92614 
(949) 760-0404 (telephone) 
(949) 760-9502 (facsimile) 



Attorneys for Plaintiff FOUNDSTONE, IMC. 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
COUNTY OF ORANGE, CENTRAL JUSTICE CENTER 



FOUNDSTONE, INC. , a Delaware 
corporation, 

Plaintiff, 

v. 

NT Objectives, Inc., a 
California corporation; J.D. 
Glaser, an individual; Michael 
Morton, an individual; Eric 
Caso, an individual; Dan 
Kuykendall, an individual; and 
DOES 1 through 50, inclusive, 

Defendants. 



CASE NO. 02CC1530 

ASSIGNED FOR ALL PURPOSES TOt 
HON, DAVID H. BRICKNER 
DEPT, C17 

PLAINTIFF'S REPLY IN SUPPORT 
OF MOTION FOR PRELIMINARY 
INJUNCTION 
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grant the preliminary injunction. " ) . 

C. The Facts Establish Likelihood Of Success 

The second prong of the two-part test for injunctive 
relief is likelihood of success on the merits. Foundstone hcis 
clearly established that it is likely to succeed. 

1, Foundstone* s Specified Methods and T echniques Are 

Protectable Trade Secrets 
In its moving papers, Foundstone submitted detailed 
evidence that its methods and techniques in six specific areas 
constituted protectable trade secrets. (Memo, at 9-11.) In 
response, Defendants have raised a number of arguments- All 
lack merit* 

(a) The Trade Secrets Are Adequately Defined 
Defendants argue that Foundstone has not identified its 
trade secrets with sufficient particularity. (Opp. at 6^8.) 

To make this argument. Defendants ignore the specific 

identification of trade secrets con tained in Foundstone' s 
moving papers and claim that Foundstone only generically 
stated "that Foundstone' s software contains 'algorithms, 
methods, and databases,"' (Id. at 6.) This is simply 
incorrect. Foundstone' s moving papers stated that its trade 
secrets related to si* specific ally described technologies ... 
The detailed descr i ption of these technologies spanned two 
full pages of Foundatone'a brief . (Memo, at 9-11; KcClure 



Decl. 11 5-12. ) x 



1 Defendants' reliance on Diodes Inc. v, grgnsgn, 260 

Cal.ApE SdM4 (1968) is misplaced. In lWes, ^U^P^ntrff 

simply referred to a -secret process." contrast, 
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Defendants similarly assert that they are unable to 
understand the described trade secrets. (See, e^, Glaser 
Decl. 1 26.) Such assertions are implausible, given that the 
Defendants themselves allege that they had critical roles in 
developing Foundstone's software. (See, e^a, id^_ 1 38.) The 
assertions are also thoroughly repudiated by Defendants' own 
declaration; The declarations discuss specific methods and 
algorithms allegedly implicated by the claimed trade secrets 
in great detail. (Caso Decl. 111 12-18; Glaser Decl. 11 16-19; 
Morton Decl. 11 16-19.) 2 See whyte v. S chlaoe Ijdck Co., 101 
Cal.App.4th 1443, 1453 (2002) (rejecting assertion that trade 
secrets were defined too broadly where, from responses to 
discovery, it was clear that former employee had "no 
difficulty in understanding the scope of the putative trade 
secret information.") 

Moreover, the scope of trade secrets are specifically 
limited to methods developed lav Founds tone . (Memo, at 9-11.) 
The Court of Appeal has specifically held that an injunction 
"need not specify in detail the processes whose use is 

prohibited . " Components For Research, Inc. v. Isolation 

prods., Inc. , 241 'cal.app.2d 726, 731 (1966). Instead, it is 



Foundstone has provided pages of detail describing the trade 
secrets at issue. Defendants' reliance on M M . S va ■ fop^ 
Pe ak Computer , 991 F.2d 511 (9th Cxr. 1993 1, ""J™ 
misplaced In MAI, the plaintiff cryptically referred only to 
"valuable' MMenU' in software, without any further 
explanation whatsoever. 

SS-'f-Sui^Si^Si-S"» motion 2019(d) on October vs. 

2002. 
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sufficient to describe the technology and specifically limit 
the scope of an injunction to "method [s] , technique [s] . or 
processes - - - developed by the plaintiff." Id. (Emphasis 
added.) For the additional reason that the trade secrets 
claimed here are all specifically limited to methods developed 
by Foundstone, the trade secrets are described in more-than- 
sufficient detail. 

(b) The Trade Secrets Are Hot Public Domain 
Defendants also argue that Foundstone' s trade secrets are 
-based on information available in the public domain." {Opp. 
at 10.) This assertion is utterly irrelevant. Foundstone 
does not dispute that its trade secrets rely, in part, on 
known principles. Defendants, however, never claim that any 
of the publications or software they refer to in their papers 
discloses the actual methods Founds tone developed. 3 They do 
not dispute that the massive investment Foundstone had to make 
to create its software. (McClure 1 4.) Indeed, Defendants 
admit that, to duplicate the functionality of Foundstone ' s 
software, it would be necessary for a competitor to make a 
similar investment of money and effort. (Glaser H 31.) 

(c) Reasonable Efforts To Maint ain Secrecy 
Defendants also assert that Foundstone did not take 
reasonable efforts to protect the secrecy of the software. 



irrelevant* S"0»tS& UrJt^ ^ 

SSSaSiSttion. the document, howler, merely 

general ICMP methods of network scanning, not the cecnniques 

developed by Foundstone - 
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(Opp. at 10.) Defendants do not dispute the comprehens ive 
steps Foundstone has taken to protect its trade secrets. 
(McClure Decl. 11 13-20.) Instead, Defendants point only to. 
Foundstone' e alleged provision of evaluation copies of its 
software to reviewers, which would have theoretically allowed 
a reviewer to "read, write, or print- a single database. 
(Caso Decl. 1 15.) Defendants never claim that the data - an 
unintelligible mixed series of binary, decimal, and 
hexadecimal numbers - could be used or even understood by 
anyone. Defendants never state that any source code, or any 
means by which anyone could use or understand the allegedly 
compromised database was disclosed. Accordingly, there is no 
serious dispute that Foundstone took reasonable steps to 
protect its trade secrets. 

2. Defendants Have Misappropriated And Threatened To 

Misappropriate Foundstone' a Trade Secrets 
In its moving papers, Foundstone submitted detailed 
evidence establishing that Defendants had misappropriated and 
threatened to misappropriate its trade secrets, citing to 
specific features of Defendants' software. (McClure Decl. 11 
30-32.) 4 In their Opposition, Defendants do not dispute 
(indeed, they admit) that their software contains these 
features. (Caso Decl. Exh. C; Glaser Exh. E.) Moreover, 



32 ^^^^^^^^^^ 

descriptions of their- software. (Caso Decl. Exh- C, Glaser 
Decl. Exh. E.) 
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Plaintiff Foundstone, Inc. ("Foundstone") submits this 
Supplemental Reply in Support of ' the Order to Show Cause Re.; 
Preliminary Injunction. The information addressed in this 
Supplemental Reply disproves a key assertion made by 
Defendants in their Opposition. ' The information was not 
discovered by Foundstone until after Foundstone filed its 
Reply on October 25, 2002. 

In their Opposition. Defendants repeatedly argue that it 
is -impossible" for the Defendants to determine the trade 
secrets that are the subject of this action. (Opp. at 2. See 
also id, at 6-9.) The Defendants themselves submitted 
declarations, each asserting, in lock-step: "I have read the 
Declaration of Stuart McClure submitted in support of this OSC 
re; Preliminary Injunction. From review of that document I am 
unable to determine any specific method, algorithm or 
technique which is being referred to by Foundstone as a trade 
secret." (Case Decl. 1 13; Glaeer Decl. 1 26; Kuykendall 
Decl. 1| 15; Morton Decl. ^ 16.) 

Information just uncovered by Foundstone demonstrates 
that these assertions are false. As set forth in Exh. A to 
the Hudson Decl. submitted herewith. Defendant Kuykendall 
maintains a personal site on the World wide Web. On his web 
site, Defendant Kuykendall pub lished a paraqraph-by-paragraph 
critique of the McClnre Decl., specifically addressed each of 
the paragraphs of the McClure Decl. describing the trade 



secrets at issue in this action, and unambiguously admitted 



that he understood that Foundstone has proprietary technology 



in * af , h described area . The McClure Decl. described the trade 
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secrets at issue in paragraphs 7-12- In his web site. 
Defendant Kuykendall responded to each of these paragraphs ' by 

admitting, inter alia , rFoundstone3 have thei r 

proprietary implementation ." {Hudson Decl . EX. A p. 3, 11 7- 
12; emphasis added.) 

For this additional reason, Foundstone requests that this 
Court preliminarily enjoin Defendants and maintain the status 
quo pending final adjudication of this matter. 

Respectfully Submitted/. 
KNOBBE, MARTENS, OLSON & BEAR, LLP 



Dated 



7^0 D1- 




Darre_^ 
Michael 

Douglas T. Hudson 
Attorneys for Plaintiff 
FOTINDSTONE , INC. 
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Introduction 



1.1 Introduction to Version 1.0 „ , . n 

The ICMP Protocol may seem harmless at first glance. Its goals and features were outlined in 
RFC 792 (and than later cleared In RFC* 1122. 1256. 1349. 1812). as a way to prov.de^ means 
to send error messages. In terms of security. ICMP Is one of the mo^ controversial P"*™* in 
the TCP/IP protocol suite. The risks involved In implementing the ICMP protocol m a network, 
regarding scanning, are the subject of this research paper. 

Scanning will usually be the major stage of an information gathering process a malicious 
computer attacker will lunch against a targeted nelwork. With this stage the i malicious computer . 
atecker will try to determine what ere the characteristics of the targeted network. He will use 
several techniques, such as host detection, service detection, network topology mapping, and 
SSng system fingerprinting. The data collected will be used to identHy those Hosts (rf any) 
that are mnning a nelwork service, which may have a known vulnerahllHy. This vulnerabdity may 
alow the malicious computer attacker to execute a remoteexptoit irr order - ta M^"^*" 
access to those systems. This unauthorized access may become his focal pomt to the whole 
targeted network. 

This research paper outlines the usage of the ICMP protocol In the scanning process. Step-by- 
Steo we will uncover each of the malicious computer attacker techniques using the ICMP 
protocol. A few new scanning techniques will be unveiled In this research paper. I have reported 
some of them to several security mailing lists, including Bugtraq, in the past 

The chapters in this research paper are divided according to the various scanning techniques: 

- Host Detection using the ICMP protocol is dealt in Chapter 2. 

. Advanced Host Detection methods using the ICMP protocol are discussed in Chapter 3. 

* Inverse Mapping using the ICMP protocol is discussed in Chapter 4. 

• Network Mapping using the traceivute utility is discussed in Chapter 5 

. Chapter 6 discuses the usage of ICMP In the Active Operating System F.ngerpnntmg 

. ChapTe S r'7 suggests a filtering policy to be used on filtering devices when dealing with the 
ICMP protocol. 

I would Dke to take a stand In this controversial issue. ICMP protocol hazards are not widely 
known. I hope this research paper will change this fact. 

this paper. 

See section 1 3 for a full Changes list 



1 See Section 6 for nnore jnformstifin. 
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1 3 Introduction to Version 2.5 

With this version of the research paper I am introducing a few new OS fin 9 e ^ rmta "9^^^: 
Some are targeted in producing ICMP error messages from a target OS, enabling us to fingerpnnt 
an OS even if all ports of the OS in question are closed. I have also added a considerable amount 
SSlSSon iout ICMP error message. At the end of the paper you will find the Basic snort 
rule base I have written. 



1.4 CHANGES 

1.4.1 Version 1.0 to Version 2.0 

2*0 Host Detection Using the ICMP Protocol. 

2.3 Draa ^| t d 1 g , ^ !e descr i 0 ing which operating systems would answer an ICMP ECHO 

request aimed at the Broadcast address of the network they, reside on, 

2.4 Non-ECHO ICMP ^ ■ „ A . . 

Added Information Request and Reply as a valid Host Detection method. 

2.4.2 ICMP Information Request and Reply 

The actual Information (added a section)* 

2.4.3 ICMP Address Mask Request and Reply 

Added SUN Solaris and networking devices examples. 

2.5 Non-Echo ICMP Sweep tj ' 

Added a table summarizing which operating systems would answer those 

queries. 

2 6 Non-ECHO ICMP Broadcasts 

Added the feet that "Hosts running an operating system, which answers 
requests aimed at the IP broadcast address.. 

Added two tables describing which operating systems would answer to which 
type of ICMP queries aimed at the broadcast address of the network they reside 

3 0 Host Detection Using ICMP Error messages generated from the probed machines 

3.1 IP datagrams with bad IP Header fields 

Added more information on various other, fields which can be used for this 

purpose, 

6.0 The Usage of ICMP in the operating system Finger Printing Process 

6 1 Using Wrong Codes within ICMP Datagrams 

6^1 Using ICMP Timestamp Requests with Codes different than 0 
612 Listing ICMP query message types sent to different operating systems 
with the Code flew 1^0 and the answers (Is any) we got 

6.2 Using ICMP Address Mask Requests (identifying Soton \Mfh.nes) 

6.3 TOSing OSs out of the Window / Fingerprinting Microsoft-Windows 2000 

6.7 Using ICMP Address Mask Requests 

6.8 Using ICMP Information Requests _t=run irwP 

6.9 Identifying operating systems according to their replies for non-ECHO ICMP 

requests aimed at the broadcast address* 
6 10 IP TTL Field Value with ICMP 

6 10 1 1P TTL Field Value with ICMP ECHO Replies 
610 2 IP TTL Field Value with ICMP ECHO Requests 
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6.11 DF Bit • 

6.12 OF Bit Echoing 

6.12.1 DF Bit Echoing with ICMP Echo requests 

6.12.2 DF Bit Echoing with ICMP Address Mask requests 

6.12.3 DF Bit Echoing with ICMP Tlmestanip requests 

6.124 Using all of the Information In order to Identify the maximum of operating 
systems. 

6.12.5 Why this would work (for the skeptical) 
6 13 What will not provide any gain compered to the effort and the detection ability? 
6.13.1 Unusual big ICMP Echo messages 

7.0 Filtering ICMP on your Filtering Device to Prevent Scanning Using ICMP 

7.3 Other Considerations 

More information was added. 

APpend %Jendlx C: Table - Mapping Operating Systems for answeringWiscarding ICMP query 
Message types. ... ~ j _ . . ._ n 

Appendix D: Table - ICMP Query Message Types with Code Field !-0 
Appendix E: Table - ICMP Query Message Types aimed at a Broadcast Address 
Appendix F: Table - ICMP Query Message Types with TOS !=0 
Appendix G: Table - DF Bit Echoing 

1 .4.2 Version 2-0 to Version 2.01 
The Introduction was re-written 



1.4-3 Version 2*01 to Version 2.5 

To Section 4 "Inverse Mapping- more information and explanations were added. 
Section 6 is now divided into four main subjects: 

* Fingerprinting using regular ICMP Query requests 

* Fingerprinting using crafted ICMP Query request 

* Fingerprinting using tCMP Error Messages 

* Not that useful fingerprinting methods 

Multiple new fingerprinting methods based on ICMP Error Messages were introduced, 

i have also introduced few Fingerprinting method based on ICMP Query ^ssages^ Vgta 
UnS(SSS Sun Solan's & HP-UX 10.30 & Itjflr. '^^^^ff^ 
ULTRIX IdentrficaW, The TOS Byte Unused Bit Echoing {Identifying W,n2k r ULTIX) . 

The DF Bit Playground" fingerprinting method was better explained and explored. 

Appendix A now Includes explanation for the various ICMP Error Messages. 



o 
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5 o Host Detection using the ICMP Protocol 2 

M d52C£L. give! a Vicious computer attacker ^nL^KS b^ngs 
thfl comouters on the taroeted network thai are reachable from the Internet Jh s process Belongs 
SffS^^S* h one Of the first stages in the Information Gathenng PTOOMbTte 
i^fnr^S eoHerfed during this Stage could later lead to an attempt to break in to oris (or more) 
SSSS£tSM »SS^ This, information garnered would be sufficentfor the 
malicious computer attacker. 



£i assssas sis? skk-l . ^ - add*** . s «*. 

SS MWkSSS KfeTfiSwa.., spoof .CMP ECHO replies ^Pj-JJ 
S No response moans the target is down or a filtering device .s prevenhng * e 
ICMP ECHO datagram from getting inside the protected network or the filtering device prevents 
the initiated teply from reaching the Internet. 




ICMP ECHO request 



If alive and not filtered - ICMP ECHO 
Reply 

Figure 1: ICMP ECHO Mechanism 




This mechanism Is used by the Ping command to determine if a destination host is reachable. 
In the next example two LINUX machines demonstrate the usage of Ping: 

troot®stan /roocltt ping 192.168.5.5 «'",'. S c<84) bytes of data. 

pi»S 192.168.5.5 (192-168.5 51 fro* J^f 8.5.1 . *J 

G4 bytea from 192-168.5.5, ictt*_seCf-0 «1-25S txme 4.4 «> 

64 bytes from 192. 168. 5. icmp_se<Z=l ttl=255 ti«ne=b.» ms 

It bytes from 192.168-5.5= ictop_ B eq=2 ttl=255 tin,e=5.8 «a 



.5.5 ping statistics 

packets r<*£ 
round- trip min/avg/max = 4.4/5.3/5.9 ms 



Yl^l^^^T^^s received, a* packet loss 



^-^6:25.746316 192.16.8.5.1 1D2.168.S-5 

^ For mora Wbrmallon about the ICMP^col pl^e read ^'^^^80 reque** aimed at 

* F«xn a teem**. cf v**: The sendir* JJ^M-JjJ^ £SSSS2SL»^ 
difierent destination hoste) and sequence "^"*^g?B ^nation host. In the ICMP heoderthe coda 

* Snort, written by Martin Roesch. be found at btteffiMQgt^ - 
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ICMP TTL:64 TOS : OxO It>:6059 

S'ZTS. o. » OA OB oc o. n « ..-='= 

s s s s s s a s s s s s s s s s .i;«~' ,i;;:::> 

30 31 32 33 34* 35 36 37 

01/26-13:16 =25-746636 1M.16B.5-5 -> 1M.168.S.1 
ICMP TTLi255 TOSiQXO I&:6072 

S'SPi. ^n"?"- - - - - - - 

.xsssssssssasssss S 0 **- 7 

30 31 32 33 34 35 36 37 



16 



31 



0 


4 








TVp& 




Ctjdo»o 






far 




V$t2L» 



Figure 2: ICMP ECHO Request * Reply message format 



Countenneasure: BlocK ICMP ECHO requests coming from the Internet towards your network at 
your border router and/or Firewall . 

SSTSfflSS! ECHO ,0 nrfe^ to as ICMP Sweep (Of Pitts 
before proceeding to the next one. 

*tf is a UNIX utility which sends parallel ^^JS^^fSSS^i^ 
enabling it to be significantly faster ^^^^t'^oUP^^s which would be 

hostnames of the probed machines If using the -d option. 

^^^Tunwonted ^mo * your border *u.er. ***Q ^ far your flrswaH. 
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Kiss^csaffi r 

(Stan & Kenny) and one Windows NT wk««>* \ 
machines answered the probe: 

r.ootastan /*«*]# ~* " PI *~-««- a - Wtf • 

Startin9 ^ V. a.3B fr *y ( 

iriro. insecure. org/nmap/ » , 68 s x) appears to *» up- 

Sst stan.9ys-security.com ^«.1G8 a . ^ w fco be up . 

Host cartman.^y^^cur^com ll^ g ^ (j hogts up) scanned m 
Ntnap run completed — 2Q if 

^ H , ^olvim, done by NMAP we shoUd use the -n option to 
If we wfeh to avoid the automatic resorvmgoone y 



eliminate it, „ tertM! \ whether launched in the 

Mellv detected by IDS (intrusion Detection Systems) whether 
ICMP sweeps are easl^detej^a Dy \ 
regular way. or if used in a parallel way. 

your border muter and/or Firewall. 

2.3 Broadcast JCftrlP a(jve hosts te b y sending an ICMP ECHO request to 

the broadcast address or 10 me ^ send 

Reply) 10 an ^ P J™ ,„ r SS,r those ouenes «it-of-»» ^ i^T^K^o, pac*balowSP4). 
wSc« 

^^^^ 

different and Indudes the te _ communication Uycrs. IflaiBM BW a 1 "* 

CODVrifiht© OflrAiWn.2000-2001 
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fCMP £ cto Request^) 



Broadcast Address 
NetowrK Address 




Figure 3: Broadcast ICMP 

Ignored It. 

rrootsatan /rootl# ping -b 192.168-5.255 

25= £= S:iS:S:i: ffiSS S3S 3=*:! = -» 

PING 192.168-5.0 ^192.168.5 0) from time -7.5 ms 

round-trip tnin/avg/ma* = 7.5/b.j/» 

n » a o^-OT-Mrrt* condition if a lot of machines response 
Note: Broadcast ICMP may result in a Demal-OfService 
to the query at once. 
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A more accurate teble that lists which operating systems would answer to an ICMP ECHO 
request aimed at their Network / Broadcast address ,s given below: 



Operating Systern 


-Echo ftequosl 
Broadcast 


"Deblen GNU/ UNUX ^ Kernel ZA tesi z 
Redhal LINUX 6.2 Kernel 25.1 4 


+ 


Free BSD 4.0 
FrecBSD 3.4 
OpenBSD 2.7 
CpenBSD 2.6 
NetfiSD 




Solaris 2.5.1 
Solaris 2.6 

Solaris 2.7 - 
Solans 2.6 


+ 


HP-UX v1 0.20 


+ 


ATX 




ULTRIX 




Windows 65 
Windows 98 
Windows 9B SE 
Windows ME 

WmdowsNT4WRKSSP3 
Window* NT 4 WRKS SP 6a 
Window NT 4 Server SP4 
Windows 2000 Professional (and SPi) 
Windows 2000 Server (and SP1) 





Tamei.wnicnupera a y AddresS of the Neiywrk they reside on? 



Countermeasure; 



: Block the IP directed broadcast on the border router. 



Non-ECHO ICMP message, are being used lion rnojj -^.CMP scanning techniques (not 
only probing hosts, but network devices, such as a router, as well). 
The group of ICMP query message types includes the following: 

ECHO Request (Type 8). and Reply (Type 0) • 
Time Stamp Request (Type 13). and RepryCl £e JJ) 
Information Request (Type 15), and Reply (Type >16) 
Address Mask Request (Type 17), and Reply (Type 18) 
R^ Sollcitation (Tvpe 10), and Router Advertisement (Tvpe 9) 



14 
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Z4.1 ICMP Tinw ^™P ^^»&J 3 >£2! S Smoother fcr ■» «™m*»* 
The ICMP nm> JfTlSS IN ™ pitaKa. pet«»« is experiencing. 

elapsed since midnight UT (GMT). 



0 

_ code 


Checksum 









Figure* ICMP Time Stamp Request & Reply message format 

As RFC 1122 state, a Ik* m ay .mp^entTfcnestarpp and Timestemp Reply, 
implemented a host must follow this rules: 



O 

o 



iM» v»fal*ly *tey n ^'^SSSSSWherec*^. 

I sKi- a ^ ir. - "-ssaasssa ™ a ° " SP8 *" 

d«li™iion endless of the ""^ffrf"?.^ «" nrtnn >°ule muslne 

the Timestamp Reply message, 
E^Sted the ICMP TePesMW messaaes. 



15 
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In the next example I have sent en ICMP Time Stamp Request, using the tampush 11 tool, to a 
Rednat 6.1 LINUX, Kernel 2.2.12 machine: 

irootoscan /rootl* icrapush -tatamp 192.168.5.5 
kenny.sys-security.com -> 13s48-.07 

f!^6 T ^ : 5 l: 2 9. 34 2647 152.168-5.1 192.188.5.5 
ICMP TTL:254 TOS^OxO ID:13170 

S^T STJSTS « » 00 00 00 00 00 00 oo oo c= 

01/26-13=51:29.342885 192.168.5.5 -> 192.168.5.1 
ICMP TTI»;255 TOS:OxO IDt6096 

If? 5 6 T D f of 8 B 63 3D 02 88 50 18 02 88 50 18 ......*..»...». 

2A DE 1C 00 AO F9 

•implementation choice as RFC 1122 states. 

Countermeasure: Btock ICMP Time Stamp Requests coming from the Internet on the border 
Router and/or Firewall 

2,4.2 ICMP Information R ^ s ES n S ffiSpS self-configuring systems such 
roKsS 

The sender fills in the request with the Destination IP ^SSiSlSSi and Delation IP 
(meaning this network). The request .mm 'b. ^SSSSSSSSSS^m. both used to 
Address set to zero. The sender Inrtialtes the .deobfie r andtne seq ^ code field Is 

match the replies with the requests, and sends out the request, 
zero. 



bom the source and destination fields of the IP header. 

understand that the ICMP Information request and reply 



From the description above one can 
mechanism was intended to be used locally. 

The r*RP,BOOTP & DHCP P ro^ 
IP address. 



« icmpush waB written ^r^^^^^^ ' 
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31 



Typo 


Codd*0 


Checksum 


Men 


•liner 


Sequent Number 



Figure S: ICMP Information Request & Reply message format 

The Information Request & Reply mechanism is now obsolete as stated in RFC \\ 22 ^ 
1B12 12 . A router should not originate or respond to these messages; A ho$t should not implement 
these messages. 

Demands on one hand and reality oh the other. 

RFC 792 specifies that the Destination IP address should be set to zero, this mean that hosts that 
do not reside on the same network cannot send these ICMP query type. 

But what would happen if we would send an ICMP Information Request with the Destination IP 
address set to a specific IP address of a host out In the void? 

The next example illustrates that some operating systems would answer these queries ever i if not 
issued from the same network. The ICMP Information Request quenes we are sending are not 
really RFC compliant because of the difference In the Destination IP address. 

Those operating systems that answer our queries work in contrast to the RFC guidelines as well. 
We would see in the next example why. 

In the next example 1 have sent an ICMP Information Request, using the SING 13 tool, to an AIX 
machine: 

trootaaik icmp]# ♦ /fling -info host_addxes6 14 
SINGing no host address (ip_address) : a data bytes 
S bytes from ip^addrese : icmp_eeq=0 ttl^236 Info Reply 
8 bytes from ip_address; icmp_seq=l ttl«238 Info Reply 
S bytes from ip_address: icrop_seq»2 ttl^238 Info Reply 
$ bytes from ip_addres&: icmp_seq«3 ttl=238 Info Reply 

— host address sing statistics — 

5 packets transmitted, 4 packets received, 20* packet loss 



The tcpdump trace: 

19:56:37. 943673 pppO > x.X.x.x > y-y-Y-Y* 

4500 001C 3372 OOOO ff 01 I6a7 x*xx xxxx 

yyyy yyyy ofoo bee3 32ic oooo 

19:56:38.46X427 pppO < y,y.y.y > ionp: »J~J*~ ^ Y 

4500 ooic eeib oooo eeoi.ffifd yyyy yyyy 



« RFC 1812: Requirements for IP Version 4 Routers. 

rn^ai^ te now obsolete - A muter shou/rf nor originate or respond to these merges, A nosl ^ouia nor pi 

^NG^Tby Aifredo Andres Omen*, can be found at ^^g^ ^ to ldenfif y „. 

14 Since I have queried a production system for this test with a permission of It* owners, I do not wish to identity «- 
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xxxx 30cxx 1000 bde3 321e 0000 



Lots do a quick analysis of the trace. 
The ICMP Information Request 



Value . 


Field . • 


Additional Information 


4 


4-Bit Verafon 


IP Version 4 


5 


4-Bft Header Length 


4 x DWORD =20 Bytes 


oo 


8-Bit TOS 




001c 


16-Btt Total Length 






1$ Identification 




00 00 


3-Bll Flags + 13-hlt Fragm&nl Offcet 




If 


0-Bit TTL 


TTL«25S 


01 


8-Bit Protocol 


1=ICMP 


1ft a7 


16-Bit Heeder Chectegrn 




8b 5cd0.15 


32-blt Source IP Address 


139,92J20B^1 




32-Bit Destination IP Address 




Of 


6-BKType 


Type=l5 


00 


6-Bit Code 


Code=Q 


be a3 


16-BH Checksum 




321c 


16-Bit Identifier 




00 00 


16-BH Sequence Number 





The ICMP Information Reply: 



Value 


Field" - '■' .:- ' 


AddiUonal InformaUufi 


4 


4-BHVerelon 


IP Version 4 I 


5 


4-Bit Header Length 


4 x DWORD =20 Bytes 


00 


0-Bit TOS 


TOS°0 


00 1c 


15-B« Total Length 




061b 


16-BH kfcntfflcatlon 




00 00 


3-Bit Rags + 13-bit Fragment Offset 






8-8 rt TTL 


TTL=239 


01 


fi-BU Protocol 


1=ICMP 




16-Bit Header Checksum 




XX XX XX XX 


Source tP Address . 




8b 50 0*015 


32-Bit Destination IP Address 


13S.92.20&21 


10 


O-Bfttype 


Type^lG 


00 


e-B'rtCode 




bde3 


16-Bit Checksum 




321c 


16-Bit Identifier ■ 




00 00 


16-Bit Sequence Number 





Instead of having the network address In the Source IP Address we are getting the IP address of 
the host 

Does the reply compliarrt with RFC 792 regarding this Issue? Basically yes, because the RFC 
does not specify an accurate behavior 

The RFC states: To form a information reply message, the source and destination addresses are 
simply reversed, the type code changes to 16, and the checksum recomputed". 
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This means that if the ICMP Information Request is coming from outside (Destination Is not zero) 
of the network in question, the network address would not be revealed. But stilt a host could be 
revealed if he answers the request 

The request is not compliant with the RFC in my opinion because It does not fulfill its job .- getting 
the network address. 

Countermeasure: Block ICMP Information Requests coming from the Internet on the border 
Router and/or Firewall. 

2A.Z ICMP Address Mask Request (Type 17) and Reply (Type 18) 

The (CMPAddrBss Mask Request (and Reply) is intended for diskless systems to obtain its 
subnet mask in use on the local network at bootstrap time. Address Mask request Is also used 
When a node wants to know the address mask of an interface. The reply (if any) contains the 
mask of that interface. 

Once a host has obtained an IP address, it could than send an Address Mask request message 
to the broadcast address of the network they reside on (255.255.255.255). Any host on the 
network that has been configured to send address mask replies will fill In the subnet mask, 
change the type of the message to address mask reply and return It to the sender. 

RFC 1122 states that the Address Mask request & reply query messages are entirely optional. 



0 4fl 16 ,31 



Typo 


Cafe 


CNgfcsin 






StfmaaEiftEsinmk 



Figure 6: ICMP Address Mask Request & Reply message format 



RFC 1122 also states that a system that has implemented ICMP Address Mask messages must 
not send an Address Mask Reply unless it is an authoritative agent for address masks. 

Usually an Address Mask request would be answered by a gateway. 

Receiving an Address Mask Reply from a host would reveal an alive host that is an authoritative 
agent for address masks. It wm also allow a malicious computer attacker to gain knowledge about 
your network's configuration. This information can assist the malicious computer attacker In • 
determining your internal network structure, as well as the routing scheme. 

Please note that a Router must implement ICMP Address Mask messages. This will help identify 
routers along the path to the targeted network (it can also reveal internal routers if this kind of 
traffic is allowed to reach them). 

If the Router Is following RFC 1812 closely, it should not forward on an Address Mask Request to 
another network. 
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ICMP Address Mask Request aimed at a LJNUX machine would not trigger an ICMP Address 
Mask Reply, nor a request aimed at a Microsoft Windows NT 4 Workstation SP 6a box. 

In the next example I have sent an ICMP Address Mask Request to the broadcast address 
(192.168.5.255) of a class C network 192.168.5.0, spoofing the source IP to be 192.168.5.3: 

troot@stan /root]# icmpueh -w -mask -sp 192.168.5.3 192.168.5.255 

~> ICMP total size a 12 bytes 

-> Outgoing interface « 192.168.5,1 
MTU = 1500 bytes 

-> Total packet size (ICMP + IP) =32 bytes 
icmp Address Mask Request packet seat to 192. 168 .5. 25s (192.168,5.255) 

Receiving ICMP replies 



192.168. 5. 3 ... 

Type = Address Mask Request (oxli) 
Code ■ 0x0 Checksum m 0xBF87 

. Id t± 0x3B7 Seq# - 0x3 CBO 



icmpush? Program finished OK 



The snort trace: 

-*> Saort! <*- 
Version 1-5 

By Martin Roesch (roesch@clark.net, ww.clark.net/-roeBCh) 
Kernel filter, protocol ALL, raw packet socket 
Decoding Ethernet on interface ethO 

02/15-13:47:37.179276 192.168.5.3 -> 192.168.5.255 

ICMP ML: 254 TOS : 0x0 ID: 13170 

ADDRESS REQUEST 

B9 03 8E 49 00 00 00 00 



No answer was received from the LINUX machines or from the Microsoft Windows NT 
Workstation 4 SP 6a machine on our test lab. 

When I have tried to map which operating systems would answer (if at all) the ICMP Address 
Mask Requests, I have discovered that SUN Solans is very cooperative with this kind of query* 6 : 

[rootOaik icmp] # -/sing -mask -c 1 IP_Address 1$ 

SINGing to IP_Address (IP_Address) : 12 data bytes 

12 bytes from lp_Addxess: icmp_seq-0 ttl=24l mask=255.255*255. 0 

IP_Addreas aing statistics 

1 packets transmitted, 1 packets received , 0% packet loss 
[rootoaik icmp3# 



The Tcpdump trace: 



15 The -C 1 option enable SING to send only one ICMP datagram. TJie parameter can be changed to any desired value. 

16 The real IP Address and the Host address were replaced. 
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20:02:07.402229 pppO > x.X,X*X > y.y.y.y: icmp: address mask request 

4500 0020 3372 0000 ffOl 70a7 x3Ddc jDddc 

yyyy yyyy 1100 afe3 3fic oooo oooo oooo 

20:02:07.831426 pppO < y.y.y.y > x.x.x.x: icrnp: address mask is 
OxffffffOO (df) 

4500 0020 36X7 4000 fioi 3c02 yyyy yyyy 
xxxx xxxx 1200 a£e2 3flC OOOO ffff ff 00 



Our two last examples would be an ICMP Address Mask request aimed at a router (which must 
Im ptem ent ICM P Address Mask Messages) and at a switch. 

The following is an Address Mask Request sent to a Cisco Catalyst 5505 with OSS y4.5: 

inferno :/tmp# sing -mask -c 1 10. 13. 58. 24 0 

SINGing ro 10,13,58,240 {10 - 13 -58 .240) r 12 data bytes 

12 bytes from 10.13,58-240 : icmp_seqt=0 ttl=60 raask=255«255.255.0 

10. 13. 58. 24 0 Siog Statistics 

1 packets transmitted r 1 packets received, 0% packet loss 
inf erno : / tmp# 

in£emo:~# tcpdump -tnxv -s 1600 icmp 
tcpdump: listening on xlO 

10. 13. 5B. 199 > 10.13.58-240: iOttp: address mask revest (ttl 255, id 
13170) 

0000 : 4500 0020 3372 0000 FF01 FE99 0A0D 3AC7 E. . 3r. 

0Q10 : 0A0D 3AF0 1100 6BP7 8308 OOOO OOOO OOOO t . - .k. , 

10.13.58.240 > 10,3.3,58,199: icmp: address mask is OxffffffOO (ttl 60, 
id 20187) 

OOOO : 4500 0020 4EDB 0000 3C01 ,AG31 0A0O 3AF0 E. „ N v , „ .1 „ . 8 . 

0010 : OAOD 3AC7 1200 8308 0000 FFFF FFOO ..;,,.Jc^ 

0020 : 0000 0000 0000 0000 0000 0000 0000 

*C 

79 packets received by filter 
0 packets dropped by kernel 
inferno 



The last example Is an ICMP Address Mask request sent to an Intel 8100 ISDN Router on our 
network: 

[root©aik icmp] # . /sing -mask 10 - 0 - 0 - 254 

SINGing to 10. 0.0. 254 (10.0.0,254); 12 data bytes 

12 bytes from 10.0,0.254: icmp_seq=Q ttl=G4 maek=25 5 .255 -2SS.0 

12 bytes from 10. 0.0. 254: icmp_seq=l ttl=64 mask"255 .255 - 255 . O 

12 bytes from 10.0.0.254: "icmp_seq;=2 ttl=64 mask=255 .255 ,25S. 0 

10.0.0.254 sing statistics — - 

3 packets transmitted, 3 packets received, 0% packet loss 
Croot©aik icmp] # 

The tcpdump trace: 
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[rootOeiik /sroot]# fccpdutnp -x icrap 

Kernel filter, protocol ALL, datagram packet socket 
tepdump: listening on all devices 

.16:34:30,666687 ethO > 10. 0.0. 105 > 10.0.0,354: icmp: address mask 
request 

4500 0020 3372 0000 f£0l 7304 ^0a00 0069 

OaOO OOfe 1100 Dafd. e402 0000 0000 0000 

16:34:30. 6^7961 ethO < 10.0.0.254 > 10*0.0.10S* icmgp: address mask is 

OxffffffOO 

4500 0020 2cb7 0000 4001 38c0 OaOO 00£e 

OaOO 0063 1200 OafC ©402 0000 ffff ffoo 

0000 0000 0000 0000 0000 0000 0000 

Countermeasure: Block ICMP Address Mask Requests coming from the Internet on the border 
Router and/or Firewall. 



2.5 Non-ECHO ICMP Sweeps 

We can query multiple hosts using a Non-ECHO ICMP query message type* This Is referred as a 
Non-ECHO ICMP sweep. 

Who would answer our query? 

Hosts that answer to the following: 

o Hosts that are in a listening state. 

o Hosts running an operating system that implemented the Non-ECHO ICMP query 

message type that was sent, 
o Hosts that are configured to reply to the Non-ECHO ICMP query message type (few 

conditions here as wen, for example: RFC 1 122 states that a system that implemented 

ICMP Address Mask messages must nor send an Address Mask Reply unless it Is an 

authoritative agent for address masks). 



Given the conditions above, which host(s) would answer our queries? 



Operating system - 


Jntb. Request 


Tirtie Stamp Request 


Address Mask Request 


DeUan GNU/ UNUX 2.2. Kernel 2A test 2 




+ 




ftedhat UNUX 6-2 Kernel 








FreeBSD4.0 




+ 




FreeBSD3.4 








OpenBsD 




+ 




NeffiSD 








Solaris 2.5.1 






+ 


Solaris 2.6 








Solaris 2.7 




+ 




Solaris 2.8 






+ 


HP-UX vl 020 


+ 


+ 




A1XV4* 


+ 


+ 
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; Operating : System 


Info. Request 


Time Stamp Request 


Address Mask Request 


ULTRIX4.2-4.5 


+ 


+ 




Windows OS 








Windows &8 








Windows 98 SE 




* ■ 




Windows ME 








Windows NT 4 WRKS SP3 








Windows NT 4 WRKS SP 6a 






r 


Windows KV 4 Server SP 4 








Windows 2000 Prcfc&ifQnal 








Windows 2000 Server 









NelworWng Devices ; ' • ■ " ■ . ■ 


info. Request *■• 


Time Stamp Request v 


Address Mask Reques^ , 


Cisco Catalyst 5505 with OSS v4 r 5 


+ 


-t 


-f- 


Ci$oO Catalyst 2Q00XL with IOS 1 1 .2 


+ 


+ 




Cisco 3600 with IOS 11*2 








Cteco 7200 with IOS 11.3 


+ 


+ 




Intel Express 6100 ISDN Router 






+ 



Table 2: non-ECHO ICMP Query of different Operating Systems and Networking Devices 



Countermeasure: Block ICMP Information Requests, ICMP Address Mask Requests & ICMP 
Time Stamp Requests coming from the Internet on the border Router and/or Firewall. 

2.6 Non-ECHO ICMP Broadcasts 

We can send a Non-ECHO ICMP query message type to the broadcast address or to the network 
address of the targeted network. 

The request would be broadcasted to all listening hosts on the targeted network. 
Who Would answer our query? 

o Hosts that are in a listening state 

o Hosts running an operating system that implemented the Non-ECHO ICMP query 
message type that was sent 

o Hosts that are configured to reply to the Non-ECHO ICMP query message type (few 
conditions here as well, for example: a host may discard Non-ECHO ICMP query 
message type requests targeted at the broadcast address* For example an ICMP 
Timestamp Request to an IP Broadcast or IP Multicast address may be silently 
discarded). 



Given the conditions above, the answering hosts would almost always be UNIX and UNIX-fike 
machines. SUN Solaris. HP-UX, and LINUX are the only operating systems, from the group of 
operating systems I have tested, that would answer to an ICMP Timestamp Request aimed at the 
broadcast address of a network. HP-UX would answer Information Requests alrried at the 
broadcast address of a network. Non-would answer to an ICMP Address Mask Request aimed at 
the broadcast address of a network. 
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Operating System ■ .'!*'•'• 


Injo-^fequest ■ 


' Time. Slam pftaquast ' 


Address Masjc Request 


; • • :-!'■'• ■ 


: pfpadcast! 1 


.; : - Broadcast ■•• .*"■ 


Broadcast 


Debian GNU/ UNUX23. Kernel 2.4 test 2 
Redhat LINUX $-2 Kernel 2.2.14 




-*- 
+ 




FreeBSD 4.0 
FreeBSD 3.4 
OpenBSD 2.7 
OpanuSD 2.6 
NeflBSD 






- 


Solaris Z5.1 
Solaris 2.6 
Solaris 2.7 
Solaris 2.6 


• 
* 


+ 

+ 




HP-UX V10J20 








AJX4j( 








ULTR1X4_2^4.5 








Windows 65 
Windows 93 
Windows 98 SE 
Windows ME 

Windows NT 4 WRK$ 5P 3 
Window* NT 4 WRKS SP 6a 
Windows NT 4 Server SP 4 
Windows 2000 Professional (& SP1) 
Windows 2000 Server (& SP1) 









Table 3: Operating Systems, which would answer to requests, aimed at the Broadcast address 



Natworiang Devices 


.Info,! Request 


■ Time Stamp Request • 


Addrtess-Msisk Request 




, • craaocast - 




Broadcast. 


Cisco Catalyst 5505 with OSS v4,5 


+ 


+ 




Cisco Catalyst 2900XL with IOS 1 i £ 


+ 






Cisco 3600 with IOS 11.2 








Cisco 7200 with IOS 11.3 








Intel Express 8100 ISDN Router 









Table 4: Networking Devices, which would answer to requests, aimed at the Broadcast address 



Countermeasure: Block the IP directed broadcast on the border router. Block ICMP Information 
Requests, ICMP Address Mask Requests & ICMP Time Stamp Requests coming from the 
Internet on the border Router and/or Firewall. 
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3.0 Advanced Host Detection using the 1CMP Protocol (using ICMP Error 
Messages generated from the probed machines) 

The advanced host detection methods rely on the Idea that we can use various methods in order 
to elicit an ICMP Error Message back from a probed machine and discover its existence. Some of 
the methods described here are: 

• Mangling IP headers 

o Header Length Field 
o IP Options Field 

• Using non-vatid field values in the IP header 

o Using valid field values In the IP header 

• Abusing Fragmentation 

• The UDP Scan Host Detection method 

With the first method we are using bad IP headers In the IP datagram that would generate an 
ICMP Parameter Problem error back from the probed machine to the source IP address of the 
probing datagram. The second method use non-valid field values in the IP header In order to 
force the probed machine to generate ICMP Destination Unreachable error message back to the 
malicious computer attacker. The third method discussed uses fragmentation to trigger an ICMP 
Fragment Reassembly Time Exceeded error message from the probed machine. The last method 
uses the UDP Scan method to elicit ICMP Port Unreachable error message back from a closed 
UDP port(s) on the probed host(s). 

When using some of those methocts we can determine if a filtering device is present and some 
can even discover the Access Control List a Filtering Device is forcing on the protected network. 



o 4 a 16 31 



4tt 


4bft 
Hrtchr 


(TOS}»0 


1BUfcbllBn0Si<htyt8B) 






fctertffcatfcii 




ISttK^TwtCHat 






-&t*frnpfcil/cr 
(TTIO 


• flCMP) 




tttthflrtrdiBdauTi 


















CWfara<»nv> 





Figure 7: The IP Header 




3.1 Sending IP Datagrams with bad IP headers fields - generating ICMP Parameter 
Problem error message back from probed machines 

An ICMP Parameter Problem error message is sent when a router (must generate this message) 
or a host {should generate this message) process a datagram and finds a problem with the IP 
header parameters, which is not specifically covered by another ICMP error message. The (CMP 
Parameter Problem error message is only sent if the error caused the datagram to be discarded. 

We have some variants with this type of Host Detection. We send an Illegal forged datagram(s) 
with bad IP header tiekj(s) t that no specific ICMP error message is sent for this field(s). It will 

25 

Copyright © OfrAikin, 2000-2001 



898-d 602/620 d 6U-1 



20960926 V6 1 



j Eegiyuos lo'suGiJefl 1 oqqou)|-iiJQ j j iud8£ : go f 0-0E-90 



w-99:(ss-ujui) Noiivuna *2096D9Z6f6t:aiso Mmmm , w-MRomw Ml w&Jfea uj9»si»3] mm mm nmuium aovd 



ICMP Usage in Scanning 
Version 2.5 

force a Host to send bank an IGMP Parameter Problem Error message with either Code Q or 
Code 2 (When code 0 is used p the pointer field will point to the exact byte in the original IP 
Header, which caused the problem. Code 2 is sent when the Header length or the total packet 
length values of the IP datagram do not appear to be accurate) to the source IP address of the 
bad IP datagram and reveal its existence. With this type of host detection it is not relevant what 
would be the protocol (TCP/UDP/ICMP) embedded Inside the IP datagram. All we care about i$ 
the ICMP Error messages generated by the probed machine & any). 

This method is very powerful in detecting host(s) on the probed network with direct access from 
the Internet, since a host should generate this error message. Routers must generate the ICMP 
Parameter Problem error message as well, but not all of them check the correctness of some 
fields inside the IP header like a host does (processing of some fields Is done on the host only). 

According to RFC 1 122 a host should check for validity of the following fields when processing a 
packet 17 : 

■ Version Number - if not 4 a host must silently discard the IP packet 

• Checksum - a host should verify the IP header checksum on every received datagram 
and silently discard every datagram that has a bad checksum. 

A router should check for the validity of the following fields when processing a packet 16 : 

• Checksum - a router must verify the IP checksum of any packet it received, and must 
discard messages containing invalid checksums. 



The conditions outlined eliminate the usage of this method to a limited number of fields only. 

It Is possible to send an IP datagram with bad fiefd(s) in the IP header, which will get routed 
without getting dropped in the way to the probed machine. It should be noted that different routers 
perform different checks regarding the IP header (different implementation and interpretation of 
RFC 1812). When a router, because of a bad IP header, drops an IP packet and sends an ICMP 
Parameter Problem error message, H is possible to identify the manufacture of the router, and to 
adjust the wrong IP header field correctly according to a field, which is not checked by the 
manufacture of that particular router. 

A router.may be more forgiving than a Host regarding the IP header. This may result from the fact 
that a router Is a vehicle for delivering the IP datagram and a Host is the Destination and the 
place where more processing on the datagram is done. 

The downside for this method is the detection. Intrusion Detection Systems should alert you 
about abnormalities in the attacked network traffic, since not every day you receive IP packets 
with bad IP Header field(s). 

We can use this type of Host Detection to sweep through the entire IP range of an organization 
and get back results, which will map all the alive hosts on the probed network with direct access 
from the Internet 

Even If a firewall or another filtering device is protecting the probed network we can still try to 
send those forged packets to an IP addresses with ports that are likely to be opened- For 



RFC 1 122 — Requirements for Internet Host, htto://^A^J6tf.orQ/rfc/rfc1122.txt . 
18 RFC 1 812 - Requirements for IPv4 Routers, rmo://www.ietf.orn/rfc/rfc1 8 12.txt 
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example - TCP ports 21,25,80; UDP port 53; and even try to send an ICMP message presumably 
coming back from a Host/Router who generated It upon receiving data from the attacked network. 

In my opinion Firewalls/Filtering Devices should check the validity of those fields used to elicit the 
ICMP Parameter Problem error message and disallow this kind of traffic. 

An example is given here using the ISIC tool written by Mike Frantzen 1 ** ISIC sends randomly 
generated packets to a target computer. Its primary uses are to stress test an IP stack, to find 
leaks in a firewall, and to test the implementation of Intrusion Detection Systems and firewalls. 
The user can specify how often the packets will be fragmented; have IP options, TCP options, an . 
urgent pointer, etc. 

In the next example I have sent 20 IP Packets from a LINUX machine to a Microsoft Windows NT 
WRK5 4 5P4 machine. The datagrams were not fragmented nor bad IP version numbers were 
sent. The only weird thing sent Inside the IP headers was random IP Header length, which have 
produced ICMP Parameter Problem Code 2 error message as I anticipated. 

[rootflstan packetshaping] ft -/isic -a 192,168.5.5 -d 192.168.5.15 -p 20 

-F 0 -V 0 -I 100 

Compiled against Iiibnet 1.0 

Installing Signal Handlers. 

Seeding with 2015 

No Maximum traffic limiter 

Bad IP Version = 0% Odd" xp Header Length - 100% 

Frag'd Pent =' Q% 

Wrote 20 jackets in 0.03s @ 637.24 pkts/s 
tepdump trace: 

12:11:05.843480 ethO > kenny . sye-eectt*ity. com > cartman.sya- 
security.com: ip-proto-110 226 [tos 0xeG,ECT] (ttl lio, id 119, 
optlen=24 1 1 ip] ) 

12zll:05. 843961 ethO P aartman.sys-security.com > Jeenny.sye- 
seCurity.com: iqrap: parameter, problem - octet 21 offending pktr 
kenny.syB-security.com > cartman.eys- security. com: ip-proto-HO 226 
[tos 0xe6,ECT] (ttl 110, id 119, optlen=*24 [ \ ip] ) (ttl 128, id 37771?) 



Other fields we can use inside the IP Header 

In the last example we have used a bad Header Length field value to generate an ICMP 
Parameter Problem code 2-error message. 

An ICMP Parameter Problem would almost always result from an Incorrect usage of the IP option 
field as well. 

3.1.1 ACL Detection Using IP Datagrams with bad IP headers fields 
If we probe the entire IP range of the targeted network with all combinations of protocols and 
ports, it would draw us the targeted network topology map, and will allow us to determine the 
access list (ACL) a Filtering Device (If present, and not Mocking outgoing ICMP Parameter 
Problem Error messages) is forcing. 



hitpVZea»A cc.DurduQ-edu/-frantzen/ 
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Thfe, if the filtering device does not check the validity of the mangled IP header fields, and allows 
the specified traffic. 

3.1.1.1 How we determine the ACL (iCMP Protocol embedded Inside)? 

When the embedded protocol is ICMP. we send various ICMP message types encapsulated 
inside IP datagrams with bad IP headers). If we receive a reply from a Donation IP address we 
have a host that is alive and an ACL, which allows this type of rnessage 
host who generated the ICMP error message (and the Parameter Problem ICMP error message, 
is allowed from the destination host to tt>e Internet). 

If we are not getting any reply than one of three possibilities: 

« The Filtering Device disallows datagrams with the kind Of bad field we are using. 

• The Filtering Device is filtering the type of the ICMP message we are using. 

• The Filtering Device blocks ICMP Parameter Problem error messages initiated from the 
protected network destined to the Internet 

3.1.1.2 How we determine the ACL (TCP or UDP Protocol embedded Inside)? 

We can probe for every combination of protocol and port values inside an IP packet with bad \P. 
headerfs). If we would receive an answer it would Indicate that the protocol and port we used are 
allowed to the probed host from the Internet, and the ICMP Parameter Problem error message is 
allowed from the destination host in the protected network out to the Internet ^OLi^dalso 
indicate that the filtering device used on the targeted network is not validating the correctness ot 
the fields we have used In order to elicit the ICMP Parameter Problem error message. 

If the embedded protocol were either TCP or UDP, a reply would not be generated if: 

« The Filtering Device disallows packets with the kind of bad field we are using. 

• The Filtering Device filters the Protocol used. 

• The Filtering Device is filtering the specific port we are using for the probe. 

• The Filtering Device blocks ICMP Parameter Problem error messages initiated from the 
protected network destined to the tntemet In our case, the filtenng device may be 
blocking the specific host we are probing for outgoing ICMP Parameter Problem 
datagrams. 

Mote- If we are using the IP Header Length field in order to elicit ICMP Parameter problem error 

back torn the probed hostfs) than the host processing the datagram may not be able to 
SetS InforTa^n embedded inside. The reason would be the faulty calculation that 
would be made - where the header ends and the data portion begins. 

Countermeasure: Block outgoing ICMP Parameter Problem from the protected network to the 
Internet on the Firewall & on the border Router. 

Check with the manufacture of your filtering device which fields ft validates on the IP header when 
processing a datagram. 
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3.2 IP Datagrams with non-valid field values 

This Host Detection method ts based on different IP header fields within the crafted IP datagram 
that would have non-valid field values, which would trigger an ICMP Destination Unreachable 
Error message back from the probed machines. 

Mote that some hosts (AIX. HP-UX. Digital UNIX) may not send ICMP Protocol Unreachable 
messages. 

3.2*1 The Protocol Field example 

3.2.1 .1 Using naiuValid (not used) IP protocol values 

One such field within the IP header is the protocol field. If we will put a value, which does not 
represent a valid protocol number, the probed machine would elicit an ICMP Destination 
Unreachable - Protocol Unreachable error message back to the probed machine. 

By sending this kind of crafted packets to all IP addresses within the IP address range of the 
probed network we can map the hosts that are directly connected to the Internet (assuming that 
no filtering device is present, or filtering the specific traffic). 

3.2.1.1.1 Detecting if a Filtering Device is present 

A packet sent with a protocol value, which does not represent a valid protocol number, should 
elicit an ICMP Destination Unreachable - Protocol Unreachable from the probed machine. Since 
this value is not used (and not valid) ell hosts probed, unless filtered or are A1X, HP-UX, Digital 
UNIX machines, should send this reply. If a reply Is not received we can assume that a filtering 
device prevents our packet from reaching our destination or from the reply to reach us back. 

3.2.1.2 Using alt combination of the IP protocol filed values 

The difference with this variant is that we use all of the combinations available for the IP protocol 
field - since the IP protocol field has only 8 bits in length, there could be 256 combinations 
available. 

NMAP 2.54 Beta 1 has integrated this variant and Fyodor have named it - IP Protocol scan. 
NMAP sends raw IP packets without any further protocol header (no payioad) to each specified 
protocol on the target machine. If an ICMP Protocol Unreachable error message Is received, the 
protocol is not in use. Otherwise It is assumed it Is opened (or a filtering device is dropping our 
packets). 

If our goal was Host Detection only, than using the NMAP implementation would be Just fine. But 
if we wish to use this scan type for other purposes, such as ACL detection, than we would need 
the payioad data as well (the embedded protocols data). 

We can determine if a filtering device Is present quite easily using this scan method. If a large 
number of protocols (non valid values could be among those) seems to be "opened /used (not 
receiving any reply- ICMP Protocol Unreachable) than we can assume a ^enng device = is 
blocking our probes (If using a packet with the protocol headers as well), if the ffltenng device Es 
blocking the ICMP Protocol Unreachable error messages Initiated from the protected network 
towards the Internet than nearly all of the 256 possible protocol values would be seemed 
"openetfVused. 

With the current implementation with NMAP the 256 possible protocol values should be -"opened" 
when a scan is performed against a machine inside a protected network, because a P^tfilter 
firewall (or other kind of firewall) should block the probe since it lacks mformabon to validate the 
traffic against its rule base (information In the protocol headers such as ports for example). 
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In the next example 1 have used NMAP 2.54 Beta 1 in order to scan a Microsoft Windows 2000 
Professional machine: 

[root<S>cafcman /root] # nmap -w -SO 192.168,1.1 

Starting nmap V. 2,54BETA1 by fyodoaCO insecure . org ( 
www. insecure .org/nmap/ ) 

Host (192.16B.1.1) appears to be up ... good. 

Initiating F IK, NULL, UDP, or Xmas stealth scan, agai net {192 .168 . l .1 ) 
The TJDP or stealth FIN/tftTLL/XMAS scan too*: 4 seconda to scan 254 ports. 
Interesting protocols on (192 . 168- 1-1) * 

(The 250 protocols scanned tout not shown below are in state: closed) 
Protocol State flame 

1 open icmp 

2 open igmp 
6 open tCp 
3.7 open udp 

Kma p run completed -'- 1 IP adored (1 host up) scanned In 4 seconds 



A tcpdump trace of some of the communication exchanged: 

17:44:45-651855 ethO > localhost .localdom*in > 192. 168.1, It ip-proto-50 
0 (ttl 38, id 29363) 

17z44:45. «5216$ ethO * 192.1G8.1.1 > localhost . localdomam : icmp: 
192.168.1.1 protocol 50 unreachable Offending pJtt: 

localhost. localdomain > 192.168.1.1: ip-prOto-50 0 (ttl 38, id 29363) 

(ttl 128, id 578) „ CD i , ^ 

17:44:45,652431 ethO > localhoat.localdomain > 192.168.1-1- ip-proto- 

133 0 (ttl 38 , id 18) • V 

17:44:45.652538 ethO > localhost. localdomain > 132*168.1.1= rp-proto 

253 0 (ttl 38, id 36169) OS 
17:44=45.652626 ethO > lbcalhost . localdotnam > 192.168.1.1: ip-protO-92 

0 (ttl 38 f id 26465) . - 

17:44:45.652727 ethO < 192.168.1.1 > localhost - localdoma*n= icmp- 
132.168.1.1 protocol 133 unreachable Offending p*t: 
localhost. localdomain > 192.168.1*1: ip-proto-133 0 (ttl 38, id 18) 

(ttl I28 f id 579.) ~ i4 _„ 

17:44:45.652760 ethO > localhost . localdomai* > 192.168.1.1: ip-proto- 

17?44:45?6S28M^ti" > 1«-168.1.1= ip-protO-30 

0 (ttl 38, id 30441) . . . 

17:44:45.652932 ethO < - 192 . 1*8 . 1 . 1 > localhost . localdomaxn: icmp: 
192.168.1-1 protocol 253 unreachable Offending pkt: _ 3ei69 ) 
localhost. localdomain > 192.168.1.1: ip-proto-253 0 (ttl 38, ad 36169) 
(ttl 128, id 580) 

IS Srobe. If a filtering device exists then no answer (ICMP Protocol Un^A) will be 
delved torn the probed machine, assuming it te not AlX, HP-UX or Digital UNIX . 



20 You can <tetermlne ttfs using OS finger printing methods 
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If a certain protocol were not allowed through the filtering device we would not receive any ICMP 
error message from the probed machine. Probing for all combinations of protocols and ports 
against an IP range of a targeted network using non-valid and valid protocol values can 
determine the ACL a filtering device is forcing on the protected network, along with the topology 
map of a targeted network (hosts reachable from the Internet). 

A reply would not be generated if: 

• The Filtering Device filters the Protocol we are using 

• The Filtering Device is filtering the specific port we are using for the probe. 

• The Filtering Device blocks ICMP Destination Unreachable -* Protocol Unreachable error 
messages, initiated from the protected network destined to the Internet In our case, the 
filtering device may be blocking the specific host we are probing for outgoing ICMP 
Destination Unreachable - Protocol Unreachable error messages. 

Note: We can use this, method for ACL detection but If the protocol we are using is not used on 
the target machine it should be blocked on the filtering device. Than, only opened TCP/UDP ports 
and allowed ICMP traffic could traverse the filtering device. If this kind of traffic is allowed we can 
have better ACL detection solutions then we outlined here. 



Countermeasure: Block outgoing ICMP Protocol Unreachable error messages coming from the 
protected network to the Internet on your Firewall and/or Border Router. If you are using a firewall 
check that your firewall block protocols which are not supported (deny all stance). 



3.3 Host Detection using IP fragmentation to elicit Fragment Reassembly Time 
Exceeded ICMP error message. 

When a host receives a fragmented datagram with some of its pieces missing, and does not get 
the missing part(s) within a certain amount of time the host will discard the packet and generate 
an ICMP Fragment Reassembly Time Exceeded error message back to the sending host 

We can use this behavior as a Host Detection method, by sending fragmented datagrams with 
missing fragments to a probed host, and wait for an ICMP Fragment Reassembly Time Exceeded 
error message to be received from a live hostfe), if any. 

When we are using this method against all of the IP range of a probed network, we will discover 
the network topology of that targeted network. 

In the next example I have sent a TCP fragment (with the MF bit set, using the -x option with 
hping2) to a Microsoft Windows ME machine; 



(rootGgodfather bin] # hping2 -c 1 -x -y y.y.y-y 

pppO default routing interface selected (according to /proc) 

aplNG y.y.y,y (pppO y,y-y-y) s NO FLAGS are set, 40 headers + o.data 

bytes 

Y-Y+Y-Y bping statistic 

X packets tramitted, 0 packets received, 100% packet loss 
round-trip min/avg/raax = 0. 0/0,0/0.0 toS 
[roofcfcgodfather bin]# 

The tcpdump trace: 
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20:20:00»226064 pppO > x.x.x^x*1749 > y.y.y r «Y' 0 = ■ 

1133572879 :1133572S73(0) win 512 (frag 31927:2000+) (DF) (ttl 64) 
4S00 0028 7cb7 6000 4006 cSfd xxxx xxroc 
d496 6607 06dS 0000 4390 f30f 0C13 6799 
5000 0200 27a8 0000 

20:21:00-033209 pppO < Y-Y-Y-Y > X^.x.xi icrop: ip reassembly time 
exceeded Offending pktn [|tcp] (frag 31927i20qo+) (dp) (ttl 55) (fctl 
119, id 12) 

4500 0038 oooc oooo 7701 6e9e yyyy yyyy 

jdcxx xxxx ObOl b789 0000 0000 4500 0028 
7cb7 £000 3706 dlfd xxxx jqooc yyVy yyyy 
06d5 0000 4390 f30f 



3.3.1 ACL Detection using IP fragmentation 

This method can be used not only to map the entire topology map of the targeted network, but 
also to determine the ACL a firewall or a filtering device is forcing on the. protected network. 

Simply using all combinations of TCP and UDP with different ports, with the IP addresses from 
the IP range of the probed network will do it. When we receive a reply it means a host we queried 
is alive, the port we have used is opened on that host, and the ACL allows the protocol type and 
the port that was used to get to the probed machine {and the ICMP Fragment Reassembly Time 
Exceeded error message back from the probed machine to the Internet). 

If we were not getting any reply back from the probed machine rt can mean: 

• The Filtering Device filters tfte Protocol used. 

• The Filtering Device is filtering the specific port we are using for the probe. 

- The Filtering Device blocks ICMP Fragment Reassembly Time Exceeded error messages 
initiated from the protected network destined to the Internet. In our case, the filtering 
device may be blocking the specific host we are probing for outgoing ICMP Parameter 
Problem datagrams. 



3.3.1.1 An Example with UDP (Filtering Device Detection) 

Since UDP is a stateless protocol it may be better suited for our needs here. The first datagram 
would be fragmented Including enough UDP information in the first fragmented datagram that 
would be enough to verify the packet against a FirewalPs Rule base. The second part of the 
datagram would not be sent It would force any host that gets such a packet to send us back an 
ICMP Fragment Reassembly Time Exceeded error message when the time for reassembly 
exceeds. 

If the port we were using were an open port, than the ICMP Fragment Reassembly Time 
Exceeded error message would be generated. If the port were closed then an ICMP Port 
Unreachable error message would be produced. 

If a firewall Is blocking our probed than no reply would be generated. 

No reply would be an indication that traffic to the Host we probed is filtered. 



We can divide the first packet of the TCP handshake into two fragments. We would ^put ©nough 
TcVwormation In the first packet that would be enough to verify the packet ^TXtS^ 
Rule base (this means the port numbers we are using are included in the packet). We will not 
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send the second part of the packet, forcing any host that gets such a packet to send us back an 
JCMP Fragment Reassembly Time Exceeded error message when the time for reassembly 
exceeds. This would indicate the host is accessible by this kind of traffic, which is allowed using 
the port we have specified as the destination port 21 . 
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Figure 8: An Example: A TCP packet fragmented after only 12 bytes of TCP information 



If the port we are using Is open, than the ICMP error message would be generated. If the port is 
closed than a TCP RST packet should be sent back. If a filtering device were to block our probes 
than no reply would be generated. No reply would be an indication that traffic to the host we 
probed is filtered or the filtering device requires that the first TCP packet would not be fragmented 
(which is a legitimate requirement). 



3.3. 1.3 An Example with iCMP 

We can do the same wfth encapsulating the ICMP protocol. When doing so the ICMP fragmented 
packets should sound the sirens when an Intrusion Detection system (If deployed) sees them. 
There is no reason to fragment an ICMP datagram. 

If we think of sending fragmented ICMP through a bad filtering device product than we should at 
least include the first 4 bytes of the ICMP header with the IP datagram. 

Countermeasure: Block outgoing ICMP Fragment Reassembly Time Exceeded Error messages. 

ZA Host Detection using UDP Scans, or why we wait for the ICMP Port 
Unreachable 

How can we determine if a host is alive using a UDP probe? - We use the UDP scan method that 
uses ICMP Port Unreachable error message that may be generated from probed hosts as 
indicator of alive hosts. With this method we are sending a UDP datagram with 0 bytes of data to 
a UDP port on the attacked machine. If we have sent the datagram to a closed UDP port we will 



21 inacase warn a firewall is validate that the first packet Is not fragmented, wc can fr^merrt a^lher ™e in* aal But 
than tbfc scanning method would not bo any different from any other seannmd method using TCP Haas combinations. 
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receive an ICMP Port Unreachable error message. If the port is opened, we would not receive 
any reply. 

When a filtering device is blocking UDP traffic aimed at the attacked machine, it would copycat 
the behavior pattern as with opened UDP ports. 

If we probe a large number of UDP ports on the same host and we do not receive a reply from a 
large number of ports, it would took like that a large number of probed UDP ports are opened. 
While a filtering device is probably blocking the traffic and nearly all of the ports are closed. 

How can we remedy this? 

We can set a threshold number of non-answering UDP ports, when reached we will assume a 
filtering device is blocking our probes. 

Fyodor has implemented a threshold with NMAP 2.3 BETA 13, so when doing a UDP scan and 
not receiving an answer from a certain number of ports, it would assume a filtering device is 
monitoring the traffic, rather than reporting those ports as opened. 



3.4.1 A Better Host Detection Using UDP Scan 

We will take the UDP scan method and tweak It a bit for our needs. We know that a closed UDP 
port will generate an I CMP Port Unreachable error message indicating the state of the port - 
closed UDP port. We will choose a UDP port that should be definitely closed (according to the 
I ANA list of assigned ports ftp://ftp.isi.edu/?n-notes/ianafe^ For examp ^ e 

we can use port 0 (but ft would reveal our probe pretty easily). 

Based on the fact that sending a UDP datagram to a closed port should elicit an ICMP Port 
Unreachable, we would send one datagram to the port we have chosen, than: 

• If no filtering device Is present we will receive an ICMP Port Unreachable error 
message, which will indicate that the Host fe alive (or if this traffic is allowed by 
the filtering device). 

• If no answer Is given - a filtering device is covering that port 



In me next example I have used the HPING2 22 tool to send one UDP datagram to host 
192.168.5.5 port 50, which was closed: 

[root@9tan /root]# nping2 -2 192. 16© .5- 5 -p 50 -c 1 
default routing not present - 
HPING 192. 168. 5. S (ethO 192.168.5*5): udp mode set, 28 headers + 0 
bytes . 
XCMP Port Unreachable from 192.168.5.5 (kenny . ays- a ecur xty.com) 

192. 168. 5. 5 hping statiatic 

1 packets trauiitted, o packets received. 100% packet loss 
round- trip min/avg/max - 0.0/0.0/0.0 ms 



-*> Snort t <*- 
Version 1.5 

By Martin Roesch (roeschocl ax3c.net, vww.clarlc.net/-roescn) 
Kernel filter, protocol AUi, raw packet socket 



22 HPING2 written by antire*, http://Www.kv * rr, f^fanHf^/hplno/ . 
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■ r :-/i 

*\ ■ ■- 

Decoding Ethernet on interface ethO « v 

03/12-12:54:47.274056 192.168.5.1:2420 -> 192.168.5.5:50 * ' 

UDP TTL:64 TOS:0x0 ID:57254 i 
Len: B 

03/12-12:54:47.274360 192.168.5-5 132, 1GB. 5.1 
ICMP TTL:255 TOS:0xC0 ID:0 

DESTINATION UNREACHABLE : FORT UNREACHABLE * r 

OO 00 00 00 45 00 QO 1C DF A6 00 00 40 11 OF D4 E 

CO AS 05 01 CO A8 05 05 09 74 00 32 00 08 6A El 

We can use the port number we have chosen, or a list of UDP ports that are likely not being used, 
and query all the IP range of an attacked network. Getting a reply back would reveal a live host 
No reply would mean a filtering device is covering those hosts UDP traffic, end probably other 
protocols and hosts as well. 



3.5 Using Packets bigger than the PMTU of internal routers to elicit an ICMP 
Fragmentation Needed and Don't Fragment Bit was Set (configuration problem) 

If interna! routers have a PMTU that Is smaller than the PMTU for a path going through the border 
router, those routers would elicit an ICMP "Fragmentation Needed and Don't Fragment Bit was 
Set" error message back to the initiating host if receiving a packet too big to process that has the 
Don't Fragment Bit set on the IP Header, discovering internal architecture of the router 
deployment of the attacked network* 

This is in my opinion a configuration problem causing a security hazard. 




77? 6 htemet 




Border Router 



A configuration Error example. If Internet 
Routers are configured with rrax MTU 
smaller than the max. MTU the border 

router Is using, sending packets. with the 
Don* Fragment bit set that are small 

enough to pass the bonier router but are 

blggerthan the MTU on an htemal Router 
would reveal those Router's existence. 




Figure 9' Using Packets bigger than the PMTU of internal routers to elicit an ICMP 
Fragmentation Needed and Don't Fragment Bit was Set* 
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4.0 Inverse Mapping 

Inverse Mapping is a technique used to map internal networks or hosts that are protected by a 
filtering devices/firewall. Usually some of those systems are not reachable from the Internet We 
use routers, which will give away internal architecture information of a network, even If the 
question they were asked does not make any sense, for this scanning type. We compile a list of 
IP's that list what is not there, and use It to conclude were things probably are. 



We send a number of packets to different IP's we suspect are In the IP range of the network we 
are probing. When a router, either an exterior or interior* gets those packets for further 
i processing, it looks at the IP address and makes decisions of routing based on it solely. When a 
router gets a packets with an IP which is not used in the IP space / network segment of the part of 
the probed network he serves, the router will elicit an ICMP Host Unreachable (Generated by a 
router if a route to the destination host on a directly connected network is not available - the 
destination host does not respond to ARP) or ICMP Time Exceeded error mes«age(s) back to the 
originator of the datagram. If we do not get an answer about a certain IP we can assume this IP 
exist inside the probed network* 3 . 

4.1 Inverse Mapping Using ICMP (Echo & Echo Repfy) 

Theoretically speaking, using any ICMP Query Message type or any ICMP Query Reply Message 
type in order to inverse map a network using a Router is possible. 

With the next example I have sent an ICMP Echo Request to an IP that should be routed through 
a certain router (tast hop before the host): 

24 

[rootocartman] # */icmpush -w -echo Target_IP 
-> Outgoing interface - 192*168.1.5 
-> ICMP total size = 12 bytes 
-> Outgoing interface = 192.168,1*5 
-> MTU = 1500 bytes 

-> Total packet size (ICMP + XP) « 32 bytes 
ICMP Ecno Request packet sent to TargetJCP (Target_IP) 

Receiving ICMP replies , . - 



Routers_IP ... 

Type = Time Exceeded (OxB) 
Code m 0x0 Checksum « OxFSSF 

Id = 0x0 Seq# = 0x0 



./icmpush: Program finished OK 



ICMP TTL:254 TOS-.GXQ ID: 13170 
XD:12291 Seq:317 ECHO 

02/13-09:16:31.724400 Routers_IP -> 192- 1*8.1. S 
ICMP TTIi:57 TOS:0x0 ID: 7410 



23 There 1$ also a possibility that a filtering device 1$ blocking our probes, or the reptes. 

24 The real IP's of the tergal host and ihe Rout* were replaced because of legal problems that might arise when the 
ISP's personal that was u$*d would understand ft was one Of their Routers used for this experiment 
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00:13:12 prober> 192.168. 2*5 : icmps echo reply 
00 : 13 2 13 router> probes ±cmpt boat unx^achable 

Why Using ICMP Query Replies sometimes will be more beneficial than using .ICMP Query 
Message types? 

We have more chance of getting through filtering devices, that will allow replies of certain ICMP 
Query message types to get back to the issuing hosts. This might allow us to "penetrate" to 
deeper networks with our crafted reply. 

4.2 Inverse Mapping Using Other Protocols 

The technique of inverse mapping will work with other protocols as the stimulus. It will produce 
the same results since the destination Host (IP) will still be unreachable. The router one hop 
before the targeted host could not arp the host, end will Issue an ICMP Host Unreachable 
regardless of the underlying protocol used. 



io.ittt4 «a.i*a.iA rta.m.1.* 




19I1BB, 1.1 and 192.160. 1.20 ddnot, than 
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Diagram 1: The Inverse Mapping Idea 



4.3 Patterns we might see 

This type of seen will produce a numner of patterns. Not always, when we will see a router 
issuing a host unreachable it will be because some one mentto use the Inverse mapping 
technique. 

Lets look at our first example: 



Router^IP 


> 




: lcmp - 


hoot 


Host_A 


Router IP 


> 


The_Same_IP 


: i CUtp : 


host 


HOSt_D 


Route r_ 


"iP 


> 


fhe^Sanie^ I P 


: icrap : 


host 


HostjG 


Router_IP 


> 


TiL«^_Same_IP 


: lempt 


host 


Host_N 



The same host Is being used to scan an entire IP range of a targeted network. Some of the Hosts 
the malicious computer attacker tries to reach are not reachable. Still, the malicious computer 
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attacker gets an idea about what Is not reachable. Sometimes these results are the only 
indication that the malicious computer attacker will have about the presence of Hosts. 

Lets look at the next example: 

18:12:21.901256 Router_IP > 192 . 168 .46 .45 : icmp: host x.x.x.12 
unreachable 

18: 12:33. $76136 Router_IP > 192.168.59-63: icmp: host x.x.x.12 
unreachable 

I8:12i33 -676218 Router_IP > 192*3.68.59.63: icmp: host x.x.x.12 
unre a chabl e 

18:13:27.084221 Router_IP > 193.168. 114. 37s icmp: boat x.x.x.12 
unreachable 

18:13:45.559706 Router_IP > 192.168.22.91: icmp: host x.x.x.12 
unreachable 

18:13:45.559856 Router_IP > 192 . 168 ♦ 22 . 91: icmp: host x.x.x.12 
unreachable 

18:13:48.413514 Router_IP > 192;l6S.250.254: icmp: host X.x.x.12 
unreachable 

18:13:48.413681 Router_IP > 192.168.250.254: icmp: host x.x.x.12 
unreachable . 

1B:14:31. 313495 RoufcerjCP > 192.168*247.186: icmp: hoBt x.x.x.12 
unreachable 

18:14:31.313624 RouterJCP > 192 . 168 .247.186 : icmp: host x.x.x.12 
unreachable 

18:15:32.884187 ROUter_XP > 192*168.12.213: icmp: host x,x-x.l2 
unreachable 



What we see here is different Hosts (changed to 192.168.xjc) failing to reach the x.x.x.12 IP. The 
Router is sending them all an ICMP Host Unreachable error message. 

How come different Hosts (IPs) are seeking this host on such a short notice? 



Probably what we are seeing is a decoy scan. A decoy scan is a type of scan, which involves 
multiple IPs, which are fed to the network-scanning tool as decoys. The real IP Of the malicious 
computer attacker (or a machine he compromised) will be among those. For the defending side a 
question will be asked: What IP among afl IPs p which are knocking on the door, is the IP the 
attacker was using? 

With our example the IP is reported, to all seeking hosts, to be unreachable. The Router is trying 
to deliver the packet and fails with his ARP requests. 
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Diagram 2: A Decoy Scan Example 
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5.0 Using traceroute to Map a Network Topology 

Traceroute Is a Network debugging utility, which attempts to map all the hosts on a route to a 
certain destination host/machine. 

The program sends UDP (by default) or ICMP ECHO Request 25 datagrams in sets of three, to a 
certain destination host The first three datagram's to be sent have a Time-to-Llve field value in 
the IP Header equals to one. The program lies on the fact that a router should decrement the TTL 
field value Just before forwarding the datagram to another router/gateway. 

If a router discovers that .the Time-To-Live field value in an IP header of a datagram he process 
equals zero (or less) he would discard the datagram and generate an ICMP Time Exceeded 
Code 0 - transit TTL expired error message back to the originating host 

This Is when a successful round is completed and another set of throe datagrams Is sent, this 
time with a Time-to-Live field value greater by one than the last set 

The originating host would know at which router the datagram expired since it receives this 
information with the ICMP Time Exceeded jn Transit error message (Source IP address of the 
ICMP error message would be the IP address of the router/gateway; inside the IP header + 64 
bits of original data of the datagram field we woutd have additional informaiton that would bound 
this ICMP error message to our issued traceroute command). 
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Type 



Cftfe 



Unused ( 2oro ) 



Figure 10: ICMP Time Exceeded message format 



Since we increment the TTL field starting from one for each successful round (again - a round Is 
finished when the ICMP Time Exceeded in Transit error message is received) until receive^ an 
ICMP Port Unreachable error message (or ICMP ECHO Reply if we are using the ICMP ECHO 
request datagrams) from the destined machine, we map every router/gateway/host along the path 
to our destination. 

By default when sending UDP packets we use a destination port which fe probably not used by 
the destination host so the UDP datagram would not be processes and an ICMP Port 
Unreachable error message would be generated from the destined machine. The destination port 
would be Incremented with each probe sent 

We get ICMP responses provided there is no prohibitive filtering or any packet toss. 



25 Microsoft Windows NT and Microsoft Wiivdows 2000 are using the tracert command, which use ICMP ECHO Request 
datagrams as H$ default. 
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The output we see is a fine showing the Time-To-Live, the address of the gateway, and the round 
trip time of each probe. If we do not get.a response back within 5 seconds an ' is printed, which 
represents no answer. 

A regular traceroute example with ICMP would be 26 : 



sruul : ->trace route -I 10. 0.0.10 

traceroute to 10.0.0.10 (l0.O.0.10>, 30 hope wax, 40 hyt* 
packets 

1 10. 0.0.1 (lO.O.O.l) 0-540 ma 0.394 ms 0.397 »a 

2 10.0.0.2 (10. 0.0-2) 2.455 ms 2.479 ma 2.512 WKJ 

3 10.0. 0.3 (10. 0,0-3} 4.812 ma 4.760 ms) 4.747 too 

4 10.0.0*4 ilO.0.0,4) 5,010 wis 4.503 mtf 4,380 las 

5 10. 0-0. 5 (10.0.0.5) S.S20 m3 S,fl09 hib 6.051 ma 

6 10.0.0.6 (10.0.0.6) 9.504 mO 21.754 mo 20.530 ras 

7 10.0.0.7 {10. 0.0. 7) B9. BBS mr> 79.719 ms 05,918 mo 

8 10.0.0.8 (10.Q.0.B) 92.605 ms 80.3«1 ma 94.336 mo 

9 10.0.0.9 (10. a. 0.9) 94^127 me 81.764 ma 96,476 ma 

10 10.0.0.10 (10.0.0.10) 96.012 ma 98,224 ma 99-312 ma 



Lets assume that a network is protected by a firewall, which blocks all incoming traffic except for 
traffic aimed at the DNS Machine's UDP port 53. If we would perform a regular traceroute aimed 
for the DNS machine's IP address, our UDP datagrams would be sent with a destination port* 
which is probably not used on the targeted machine, and probably blocked by a Firev^ll or 
another filtering device. The traces would stop at the firewall at the entrance point to the probed 
network, 



zuul : ->tracerouto 10,0*0.10 

traceroute to lO.O.O.io (lO.O.O-io). 30 hops max, 40 byte 

paefcete M 

1 10,0.0.1 (10. 0.0.1) 0.540 ma 0.394 ma 0.397 ma 

2 10.0.0.2 (10. 0.0. 2) 2.455 me 2.479 ma 2.512 ins 

3 10.0.0.3 (10.0-0.3) 4.812 ma 4.760 ma 4.747 ms 

4 10.0.0.4 (10.0. 0.4) B.010 me 4.903 ma 4.380 ma 

5 10.0.0.5 (10.0.0.5) 5.520 ma S.809 roa fi.061 ma 

6 10.0.0.6 (10.0.0.6) 9.S84 ma 21.754 WW 20.530 me 

7 10.0.0.7 (10.0.0.7) 89.809 m3 79.719 mS 85.918 mo 
6 10.0.0.8 (10. 0.0. 8) 92.605 mfl 80*361 me 94.336 ntfl 

9 * * * 

10 * * * 



We need to set the port number to 53 in order to reach the DNS server. Since the traceroute 
program increases the port number every time it sends a UDP datag^m, we need ^o odojMi 
the port number to start with, so when a datagram would be processed by the Firey^i! and 
wouldbe examined, it would have the appropriate port and other Information ne eded to fit with 
the Access Control List. If we use a simple equation we can calculate the starting port 

(Target port ^ (number of hops * number of probes)) -1 

The number of hops (gateways) from our probing machine to the firewall is taken from our earlier 
Z2JS^^ same Ta value, each one of them uses 

a different destination port number. 



26 All examples lekan torn 'AT1«»«*»Ucb An** of IP Packet ^^J'^^^S^ 3 
Listo" by David Goldsmith and Michael Shiftman. No real examples were provided because of legal esues. 

27 A firewall should not elicit any reply far any traffic destined directly far him. 
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zuul : -^vCraeeroute -p28 10 , 0 , 0 , 10 

traflftuout* to 10-0-0.10 (10,0.0.10) , 30 Jwps maat, 40 byte paeketa 

1 10.0.0.1 [10. 0-0.1) 0.S01 tnfi 0,399 to© 0-395 mo 

2 10.0.0.2 (10.0.0.2) 2.433 ma 2.940 ms 2.4B1 MS 

3 10.0.0,3 (10.0.0.3) 4.790 ma 4.830 me 4.885 ns 

4 10.O_O_« (10.0.0,4) 5.196 mO 5.127 mo 4.733 ma 

5 10.0.0.5 tlO. 0.0, 5) 5.650 ms 5.551 nua €.165 ma 

6 10.0,0.6 (10.0.0.6) 7.820 ma 20.554 ma 19.525 ma 

7 10.0.0.7 (10.0.0.7) 86.552 ms 30.006 ras 93.447 xta 

8 10.0.0.8 (10.0.0.8) 92.009 ms 94.855 tub 88.122 ms 

9 10.0.0.9 (10.0.0.9) 101.163 ma * * 

10 * * * 



But with the regular traceroute program we now face another difficulty. After the datagram have 
passed the ACL of the Firewall (and we assume the firewail lets ICMP TTL Exceeded messages 
out) and listed the outer leg of the Firewall itself as the next hop, the next UDP datagram sent 
would be with a different port number - Than again it would be blocked by the firewall. 

A modification to the traceroute program has been made by Michael Shiftman 28 in order to stop 
the port Incrementation. One side affect from sending traceroutes with a fixed port number, which 
is allowed on the firewalls ACL, is the final datagram, which normally would generate an ICMP 
Port Unreachable message now would not be generated since the UDP port would be in a 
listening state on the probed machine and would not provide an answer. 



ZUUl i ~>traCexoute -S -p53 10. 0.0. IS 

tract route to 10.0.0.15 (10.0.0.15) . 30 hope ma*, 40 byte 
packets 

1 10.0.0.1 (10.0.0.1) 0.516 na 0.396 ms 0.390 ms 

2 10.0.0.2 (10.0.0.Z) 2.5X6 ms 2.476 ms 2.431 ms 

3 10.0.0.3 (10.0.0.3) 5.060 tns 4.648 ins 4.721 ms 

4 10. 0.0. 4 (10. a. 0.4) 5.019 ms 4.694 ma 4.973 ms 

5 10. 0.0. 5 (IQ.0,0.5) ms 5-856 TUB 6.002 CIS 

6 10.0.O.6 (lO.0-0.fi) 19.257 ms 9,002 ms 21.797 TUB 

7 10.0.0.7 (10.0,0.7) 84.753 mB * * 

8 10.0.0.9 (10.0.0.6) 96.8G4 mB 98.006 M9 95.491 TTUJ 

9 10.0.0.9 (10.0.0.9) 94.300 ma +.96.549 tnfl 

10 10.0.0.10 (10. 0.0. 10) 101.257 tub 107.164 ms 103.318 ma 

11 10.0.O.11 (1O.0.0.11) 102. B47 ras 110. 1S8 ms * 

12 10.0.0.12 (10.0.0.12) 192.196 OS 185.265 ms * 

13 10. O. O. 13 (lO. 0.0, 13) 168-151 ma 183.238 ms 163.458 ms 

14 10,0.0.14 (10.0.0.14) 218.972 m* 209.389 m* 195.686 ms 

15 10, 0.0. 15 (10.0.0.15) 236.102 »8 237.208 m* 230.185 ms 



26 hHD;//wv^.Dacketfac<0rv,net 
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6.0 The usage of ICMP in Active Operating System Fingerprinting Process 

Finger Printing is the art of Operating System Detection. 

A malicious computer attacker needs few pieces of Information before lunching an attack. First, a 
target, a host detected using a host detection method. The next piece of information would be the 
services that are running on that host. This would be done with one of the Port Scanning 
methods. The last piece of information would be the operating system used by the host 

The information would allow the malicious computer attacker to identify if the targeted host is 
vulnerable to a certain exploit aimed at a certain service version running on a certain operating 
system. 

In this section I have outlined the ICMP methods for this type of scan. Few methods are new and 
were discovered during this research. 



Using Regular ICMP Query Messages 
6.1 The "Who answer what?" approach 

The question "Which operating system answer for what kind of ICMP Query messages?" help us 
identify certain groups of operating systems. 

For example, LINUX and *BSD based operating systems with default configuration answer for 
ICMP Echo requests and for ICMP Timestamp Requests. Until Microsoft Windows 2000 family of 
operating systems has been released it was a unique combination for these two groups of 
operating systems. Since the Microsoft Windows 2000 operating system family mimics the same 
behavior (yes mimic), it is no longer feasible to make this particular distinction. 

Microsoft might have beery thinking that this way of behavior might hide Microsoft windows 2000 
machines in the haze. As we will see with the examples given In this research paper they have 
much more to team. 

The thing is there is no clear distinction between one operating system to another based on this 
data. We can onlygroup them together and try other methodologies in order to divide those 
groups a bit more - 

Other data we might use is "Which operating system answer for queries aimed at the broadcast/ 
network address of the network they reside on?* 

For the complete mapping of the operating systems 1 heve queried for this research please see 
"Appendix C: Mapping Operating Systems for answering/ discarding ICMP query message 
types", and "Appendix E: ICMP Query Message Types aimed at a Broadcast Address". 



Two examples are given in this text for the usage of Operating System fingerprinting with the 
"Who answer what?* approach. 



29 Note: If the PMTU Discovery process using ICMP Echo requests is enables with HP-UX 10.30 & 1 1.0x operating 
systems than our simple query will trigger a "retaliation - from those machines, enabling us to Identify them very easily. For 
more Information on this issue see section 6.2 
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6.1.2 Using KCMP Information Requests 

Because of the fact, that only few operating systems would repty to ICMP Information requests, 
we can group them together. 

From the information given In table 2 in Section 2.5 t we can conclude that HP-UX 10.20, AIX, 
ULTftiX & Open-VMS would be the only operating systems (among those t have tested) that 
would produce an ICMP Information reply for these queries. 

We can further distinguish between those operating systems if we would send an ICMP Address 
Mask Request and wait for the reply from the systems in question. A!X and HP-UX operating 
systems would not answer the query, while the ULTRDC & Open-VMS would. 



ICMP Information Request 




HP-UX 

ULTRIX OpenVMS Other OS's 

ATX 



ICMP Address Mask Request 




ULTRIX Open- VMS HP-UX 

AIX 



Diagram 3: Finger Printing Using ICMP Information Request Combined with ICMP Address Mask Request 



6.1.3 Identifying Operating Systems according to their replies for non-ECHO ICMP 
requests aimed at the broadcast address 

If IP directed broadcasts are not blocked, than we can identify the answering machines quite 
easily. 

The first step is sending an ICMP Timestamp request aimed at the broadcast address of a 
targeted network. The operating systems who would answer would include SUN Solaris, HP4JX 
10.20, and LINUX (Kernel version 2.2.x). We can further identify those operating systems by 
sending an ICMP Information request aimed at the broadcast address of the targeted network- 
HP-UX 10.20 would answer the query while SUN Solaris and LINUX would not To distinguish 
between those two we would send an ICMP Address Mask request to the IPs that did not answer 
in the previous step. SUN Solaris would reply to the query while LINUX machines based on 
Kernel TJlx would not 
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For complete information see Section 2,6. 



ICMP Timestamp Request aimed at the Broadcast 
Address of a Network 



Reply 




No Reply 



Solaris 
HP-UX 
UNUXKemel 2.2.14 



Other OS's 



ICMP Information Request aimed at the Broadcast 
Address of a Network 



Reply 




HP-UX 



No Reply 



Solaris 
. LINUX Kernel 2.2.14 



ICMP Address Mask Request Aimed at Specific IPs 

Reply / \ No Reply 



Solaris 



UNUX Kernel 2.2.14 



Diagram 4: Finger Printing Using non-ECHO ICMP Query Types aimed at the Broadcast Address of an 

Attacked Nelwork 



6.2 The DF Bit Playground (Identifying Sun Solaris, HP-UX 10-30, 11.0x, and AIX 
4.3.x based machines) 

RFC 791 defines a three bits field used for various control flags in the IP Header. 
Btt 0 is the reserved flag, and must be zero. 

Bit 1 ; is called the Don't Fragment flag, and can have two values. A value of zero (not set) is 
equivalent to May Fragment and a value of one Is equivalent to Don't Fragment If this flag is set 
than the fragmentation of this packet at the IP level Is not permitted, otherwise it is_ 
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Bit 2, is called the More Fragments bit ft can have two values, A value of zero is equivalent to 
(this is the) Last Fragment and a value of 1 is equivalent to More Fragments (are coming). 

The next field in the IP header is the Fragment Offset field, which identifies the fragment location 
relative to the beginning of the original un-fragmented datagram (RFC 791, bottom of page 23), 

A close examination of the ICMP Query replies would reveal that some operating systems would 
set the DF bit with their replies. 

The tcpdump trace below illustrates the reply a Sun Solaris 2 J box produced for an ICMP Echo 
Request 

17 =10:19.538020 if 4 > Y-Y-y*Y > x.x.x.x : icmp: echo r*<juesfe (tfcl 
255, id 13170) 

4500 0024 3372 oooo ffoi 9602 yyyy yvyy 
xxxx xxxx oaoo 54a4 b<sq4 oooo cbe7bc39 

863S 0800 

17:10:19-905254 if 4 < x.x.x.x > Y «Y-Y-Y * icmp; eeno reply (DF) (ttl 
233 , id 24941) 

4500 0024 €16d. 4000 eSOl 3e07 xxxx xxaoe 
YYYY YYYy OOOO 5ca4 8d04 0000 cbe7 bc39 
8635 0800 

In the recent SING CVS (12 September 2000), written by Alfredo Andres Omefla, which is 
available from httD://soyrceforoe.net/protectefelnQ > the optiort for detecting if the DF bit is set with 
an ICMP Query reply was added, after being request by me'. The following Is the same ICMP 
Echo request & reply, this time It is presented by SING: 



[root ©godfather bin] # T /sing -edxo Host_Address 
SINGing to www.openbs4.org (IP_Address) : 16 data bytes 

15 bytes from iPj^daress; icmp~seq~Q DFI ttl«233 TOS^O time=367.314 ms 

16 bytes from IP_Ai3Uiress : icmp seq^l DF! ttl^233 TOS=0 tirae^320.020 ms 
16 bytes from IP_Address: icrap"aeq-2 nPI ttl=233 TOS-0 time»370 . 037 ms 
16 bytes from IP_Address: icmp~£eq-3 DFl ttl*233 TO5=0 tiroe-330 . 025 ms 

Host_Address sing statistics 

4 packets transmitted, 4 packets received, 0% packet loss 
round-trip rain/avg/raax = 320. 020/346. Q49/370. 037 ms 



Since www.openbsd.org uses a Sun Solaris operating system* this matches our findings, 

ICMP Query replies for an operating system maintains the same behavioral patterns. Either they 
set the DF bit on all ICMP query reply types or they do not 

The DF bit would be set by default with ICMP Query replies with Sun Solaris. With HP-UX 10.30. 
& 1 1.0x, and with AIX 4.3a setting the OF Bit wfll vary from one queried host to another 
(explanation coming). It may be set with the first ICMP Query reply onwards, or after a number of 
ICMP Query replies. This detail will help us to distinguish between Sun Solaris, HP-UX 10.30 & 
1 1 ,Qx, and AIX 4.3.x operating systems. 
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!£!S!Tl KSS ICMP Echo requests- ADC 4*x do exactly the same. 

The next trace wlU help understanding the process taken by HPUX 1 0.30 & 1 1 .Ox and ADC 4.3 .x. 

Here I have sent an ICMP Echo request to an HP-UX 11.0 machine: 

„ „ „ ; r.mr>. echo request (ttl 255, 

00:27:56.884X47 pppO > y.Y-Y-Y > x.x.X.x. 

id 13170) 45oo oQ24 3372 0000 ff()1 7cS1 yyyy yyyy 

xxaoc xxxx.0800 5238 6d04 0000 dceS c339 

8b7d OdOO vvvv . icrae . ecb o reply (ttl 236, 

00:27:57.155620 pppO < x.x.X.X > Y-Y-Y-Y • icm P- 

id 41966) 45oo Qo24 a4Q2 000{) ecQl lecl jo—c 

yyyy yyyy oooo s* 38 6dQA 0000 dce5 c33S - 
8ta7d OdOO 

notable detail - the DF bit is not set In the ICMP Echo reply. 
Than something that was not expectable has happened: 



00:27:57.435620 pppO < x.xx.x > Y-y-y-Y « W» ecko request 
236. id 41985) Q5dc a4()i 4Qoo ecQl ag(}9 5acxx 

WW yyyy 0800 7652 Safcc defO 0000 0000 
VSSi obob 0000 0000 0000 0000 0000 0000 
0000 0000 OOOO 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 OOOO 0000 0000 
gooo 0000 OOOO OOOO 0000 0000 0000 OOOO 
OOOO 0000 OOOO 0000 0000 OOOO 0000 0000 
OOOO 0000 0000 0000 0000 0000 OOOO 0000 
. 0000 OOOO OOOO 0000 0000 0000 0000 0000 
Toll OOOO OOOO 0000 OOOO 0000 0000 0000 
0000 0000 0000 0000 0000 0000 OOOO 0000 
0000 0000 0000 OOOO OOOO 0000 0000 0000 
oooo oooo ooop 0000 0000 0000 0000 0000 

oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
loll oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo. 
oooo oooo oooo oooo oooo oooo oooo oooo 
Toll Toll oooo oooo oooo oooo oooo oooo 
Ull oooo oooo oootf oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooooooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 



(DP) (ttl 
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0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 
oooo 0000 0000 0000 0000 0000 0000 oooo 

oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo. 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oboo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo 

00:27:57. 43S672 pppO > y.y. Y-Y > x.x,X.x: icmpt echo reply (ttl 255, id 
53) 

4500 05dC 0035 OOOO ff 01 a9d$ YYYY YYYY 
xxxx. xxxx OOOO 8652 SabC defO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 

oooo oooo oooo oooooooo oooo oooo OOOO 

OOOO OOOO OOOO OOOO OOOO OOOO oooo oooo 

oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooooooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
OOOO OOOO oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo 0000 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo 0.000 oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
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The HPUX 11 X machine I have queried pinged me back! The ICMP Echo request size was 1500 
bytes. It was the maximum transfer unit my Internet Connection was allowed to process. The 
request was sent with the DF bit set. Any router along the way, trying to fragment the request 
because the MTU of the destined network was smaller than the datagram's size would fell and 
send an ICMP Error message back stating a fragmentation was required but the don t fragment 
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bit was set It would allow the sending machine to send a smaller sized datagram according to its 
PMTU discovery process/algorithm with ICMP. If for this ICMP Echo request an ICMP Echo reply 
would be received, than the PMTU Is discovered. 

00 :27i57. 885662 PFpO > Y-y*Y-7 > x.x.X-X : icoop: echo request (ttl 255, 
id 13170) 

4S"QQ 0024 3372 0000 ffOl 7c5l yyvy YYYY 
xxxx xxxx 0900 5332 6d04 0100 dde5 C339 
6383 OdOO 

00:27:SS.1S5627 pppQ < x.x.x.x > Y-Y-Y-Y : icrap: echo xeply. (DF) (ttl 
236, id 41587) 

4500 0024 a403 4000 ecOl debf xxxX XXXX 

yyyy yyyy oooo 6d04 oioo dde5 c33d 

8383 OdOO 

The following ICMP Echo Request sent from my machine to the queried HP-UX 1 1 jc just 
milliseconds after my reply to the HF^UX's query was sent It has resulted in an ICMP Echo reply 
coming back from the queried machine. This time the DF bit was set with the ICMP Echo reply. . 
Rather than sending an ICMP datagram that will be fragmented somewhere along the way to the .„ 
destination machine, it is more beneficial from performance perspective, to fragment the ICMP 
datagram on sending. Setting the DF bit on the following replies would help to maintain the PMTU 
between the two systems, if for any reason, the PMTU would be decreased. For example, 
because the datagram have used another route to the destined system- 
Sending immediately another ICMP Query message type to this particular HP-UX 11 jc operating 
system based machine, will not result in the PMTU discovery process to be repeated. The DF Bit 
would be set within the ICMP Query reply. Expect a threshold to be maintained by the HP-UX 

II jc When reached the next time we query this host with any type of communication, the 
process of determining the PMTU using ICMP Echo request will begin again. 

Why this method is bound to failure? 

• Some ISPs would configure their routers not to allow fragmented ICMP datagrams 
through. I have encountered this behavior with different ISPs I have used. 

• Some machines would be configured not to reply for an ICMP Echo requests coming 
from the Internet (if you read all of this research paper you'll do that). 

• This ability "can be used for a denial-of-service attack with the HP-UX 10.30, and/or 1 1 .Ox 
machines used as an amplifier for these attacks. Infect. HP has released a security 
bulletin dated February 13, 2000 about some issues regarding this PMTU discovery 
capability with ICMP. The bulletin states that "Depending upon the amount and nature of 
the inbound traffic, an HP-UX 1 0.30/1 1 .00/1 1 .04 system can beused to flood a target 
system with IP packets which could result in a denial of service . 

• Easy identification of HP-UX 10.30. 1 1-0x machines that had the default behavior not 
changed. 

This gives us the ability to distinguish between Sun Solaris machines, HP-UX 11. Ox/1 0*30 
machines, and AIX 4.3.x based machines. 

Sun Solaris sets the DF bit with the ICMP Query replies the operating system answers for. In 
order to support its global PMTU discovery process. If the networking link will not let the ICMP 
Query reply to get back to the querying host, because the MTU used is higher than the allowed 



30 HP Security Bulletin - -Security Vulnerability with PMTU atr*tefly (revised)". February 13. 2000. 
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and fragmentation is not allowed {the DF Bit is set), than the size of the MTU used should he 
towered. There !s no active measures with Sun Solaris as far as I know- 

ThiS is a simple operating system fingerprinting method, which does not require additional or 
unusual patterns to be set 

The following operating systems where queries and checked for this kind of behavior 
Linux Kernel 2.4 test 2.4,5,6; Linux Kernel 2*2.x; FreeBSD 4.0, 3.4; OpenBSD 2.7,2.6; 
NetBSD 1.4.1.1-4.2; ESDI BSD/OS 4.0,3.1; Solaris 2.6.2.7.2-8; HP-UX 10.20. 11.0x; 
Compaq Tru64 5.0; AiX 4.1 ,3.2; Irix 6.5.3, 6.5.8; Ultrix 4.2 - 4.5; OpenVMS v7.1-2; 
Novel Netware 5.1 SP1 ♦ 5.0, 3.12; Microsoft Windows 98/98SE/ME, Microsoft Windows NT 
WRKS SP6a, Microsoft Windows NT Server SP4. Microsoft Windows 2000 Family. 



6.2.1 Avoidance 

With Sun Solaris and HPUX operating systems we can use a configuration option in order not to 
use the DF bit with the ICMP Query replies 51 . With HP-UX 10.30 and 1 1 .x it would not allow the 
Path MTU Discovery process with ICMP Query replies to be done. Thts would avoid the 
fingerprinting method I have introduced, which is based on the fact the DF bit is set on ICMP 
Query replies from Sun Solaris, and HP-UX 10.30, and 1 1.x. 

With HP-UX 10.30. & 11. 0 32 , one of the ndd command option is the lp_pmtu_strategy. The 
variable settings for this option are either 1 or 2. If this bit value is 2, than the Path MTU 
Discovery Process is used with ICMP Echo Requests. This is the default value. If this bit value 
equals 1. than the HP-UX machines will not use the ICMP echo-request PMTU discovery 
strategy, and will not set the DF bit after determining the accurate PMTU. 

To turn off ip_path_mtu_discovery on a Sun Solaris, machine use the following command as root: 

# ndd. -set /dev/ip ip_path_ratu_cliscovery 0 

Than when the ICMP Echo Reply is sent (this example) the DF bit is not set 



# SING vl.0i>eta7 initiated on Host_Address at Thu Sep 14 10 - 01: 02 2000 

# Command line: 

# -> sing -c 1 -L HoetAddreae 

SIWGing to Hbst_Addxees (I»_AddreflS) t 16 data bytes 

IS bytes from 10.13 -S7. 20 x icmp_seq=Q ttl~254 TOS=0 fcime-1.578 ma 

Host_AddrcDa sing statistics 

1 packets transmitted, l packets received, 0% packet loss 
round- trip min/avg/max = 1. 578/1.578/1-578 me 

# SING finished at Tim Sep 14 10:01:02 2000 



This was tested against Solaris 2.5.1, Solaris 2,6 and Solaris 2.7, aU SPARC boxes. 

Beware - With Sun Solaris turning this option off. Will turn off the PMTU discovery process with 
TCP as well. This Is not recommended because of performance issues. 



31 1 do not have any Information regarding AIX 

32 Building a Basfion Host Using HP UX 11, Kevin Stevens. httpiffpet^Q.hp^tBV&sk/b^gHonll.htn)!. 
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6.3 The IP Time-to-Live Field Value with ICMP 

The sender sets the time to live field to a value that represents the maximum time the datagram is 
allowed to travel on the Internet 

The field value is decreased at each point that the Internet header Is being processed. RFC 791 
States that this field decreasement reflects the time spent processing the datagram. The field 
value is measured in units of seconds. The RFC? also states that the maximum time to live value 
can be set to 255 seconds, which equals 4.25 minutes. The datagram must be discarded If this 
Meld value equals zero - before reaching its destination. 

Relating to this field as a measure to assess time is a bit misleading. Some routers may process 
the datagram tester than a second, and some may process the datagram longer than a second. 

The real intention Is to have an upper bound to the datagrams lifetime, so infinite loops of 
undelivered datagrams will not jam the Internet. 

Having a bound tp the datagram's lifetime help us to prevent old duplicates to arrive after a 
certain time elapsed. So when we retransmit a piece of information which was not previously 
delivered we can be assured that the otter duplicate is already discarded and will not Interfere 
with the process. 

The IP TTL field value with ICMP has two separate values, one for ICMP query messages and 
one for ICMP query replies. 

The TTL field value helps us identify certain operating systems and groups of operating systems. 
It also provides us with the simplest means to add another check criteria when we are querying 
other host(s) or listening to traffic (sniffing), 

€.3.1 IP TTL Held Value with ICMP Query Replies 

We can use the IP TTL field value with the ICMP Query Reply datagrams to Identify certain 
groups of operating systems. The method discussed in this section Is a very simple one. We send 
an ICMP Query request message to a host If we receive a reply, we would be looking at the IP 
TTL field value in the ICMP query reply. The next table describes the IP TTL field values with 
ICMP Echo replies for various operating systems. According to the table we can distinguish 
between certain operating systems: 




• ; ) 



Operating System 



IP TTL on ICMP datagrams 



in Reply 



LINUX Kernel 2.4 
Kernel 2^.14 
Kernel 2.0.x 33 



255 
255 
64 



FreeBSD4.0 
FreeBSD 3,4 
OpenBSD 2,7 
OpenBSD 2-6 
NetBED 



BSD! BSD/OS 4.0 
B5DI BSD/OS 3.1 



255 
255 
255 
255 
255 
255 
255 



33 



Sl&phane Omnes provided Information about LINUX Kernel 2.0 jc 
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fV _ iff n__n iwirtm 

Uperaurig oysrem 






* m JI1 f USUI J 


Solaris 2.5.1 

Solaris 2.7 
Solaris 23 


255 
255 
255 
253 


HP-UX vlO.20 | 
HP-UX v11.D 


255 

25S 


Compaq Tru64v5.Q 


64 


Irix 6.5-3 

Irix 6.5.9 


255 
255 


AIX4.1 
ADC 3.2 


255 
255 


ULTR1X 4^-4.5 


255 


OpenVMS v7.1-2 


255 


Windows 95 " 
Windows 98 
Windows 98 SE 
Wlnctows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS 5P 6a 
Windows NT 4 Server SP4 
Windows 2000 Family 


32 
128 
128 
128 
12B 
128 
128 
128 



Table 5: IP TO_ Field Values in replies from Various Opening Systems 

If wo would took at the ICMP Echo replies IP TTL field values than we can Identify a few patterns: 

* UNIX and UNIX-like operating systems use 255 as their IP TTL field value with ICMP 
query replies. 

• Compaq Tru64 5-0 and LINUX 2.0.x are the exception, using 64 as its IP TTL field value 
with ICMP query replies. 

* Microsoft Windows operating system based machines are using the value of 128. 

• Microsoft Windows 95 is the only Microsoft operating system to use 32 as rt3 IP TTL field 
value with ICMP query messages, making it unique among all other operating systems as 
well. 

WHh the ICMP query replies we have an operating system that is cteariy distinguished from the 
other - Windows 96. Other operating systems are grouped into .the * 64 group- (LINUX based 
Kernel 2.0.x machines & Compaq Tru64 S.0), the "255 group" (UNIX and UNIX-like), and into the 
"128 group 1 " (Microsoft operating systems). 

We are not limited to ICMP ECHO replies only. We can use the other ICMP Query 

types as well, and the results should be the same. In the next example an ICMP Timestamp 

request Is sent to a Redhat 6.1 LINUX, Kernel 2.2.12 machine: 

trootestan /root] # icmpush -tatarap 192*168.5.5 
kenny.sys-security.com -> 13 =48? 07 
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The Snort Trace: 

01/26-13:51:29.342647 192.168-5-1 -> 192.168-5.5 
ICMP TTL;254 TOS:0xO ID: 13170 
TIMESTAMP REQUEST 

88 16 D8 D9 02 88 63 3D 00 00 00 00 00 00 00 00 c« 

01/25-13:51:29.342885 192 . 3.66.5 •$ -> 192-168.5.1 
ICMP TTL-.255 TOS:0xQ ID:6096 
TIM^STAMF REPLY 

86 16 D8 D9 02 8B 63 3D 02 88 50 18 02 88 50 lfi c«. .P. .-P. 

2A DE 1C 00 AO F$ 

IP TTL field value is 255 (tne machine is on the same LAN). 

We can use this information with other tests as, to provide us extra criteria with zero effort 



6.3.2 IP TTL. Field Value with ICMP ECHO Requests 

The examination of the IP TTL field value is not limited to ICMP Query replies only. We can leam 
a lot from the ICMP requests as welL The following Is a Table summarizing various operating 
system default values for the IP TTL field embedded inside an ICMP Query request: 



Operating System j 


IP TTL on ICMP datagrams 


•IP TTL'on ICMP 'dat^ramfi 




-In'Repty- '' 


. -hv'ftaq. - ' " "*" *" 


Dablan GNU/ UNUX 24 Kernel 2.4 test 2 


255 


64 


Redhat LINUX 6.2 Kernel £2.14 


255 | 


64 


LINUX Kamal2.0jc 


64 


64 


FreeBSD 4,0 




255 


Free BSD 3.4 


255 


255 


OpenBSD 2.7 


255 


255 


Ope n BSD 2.6 


255 


255 


NfftBSD 


255 




BSDI BSD/OS 4.0 


255 




BSDl BSD/OS 3.1 


255 




Solaris 2.5.1 


255 


255 


Solaria 2.6 


2SS 


255 


Solaris 2.7 


255 


255 


Solaris 2.8 


255 


255 


HP-UX vl 0-20 


255 


255 


HP-UX v1 1.0 


255 




Compaq TruS4 vfLO 


64 




Mx 6.5.3 


255 




Irix 6.5.8 


255 




AIX4.1 


255 




ADC 3^ 


255 




ULTRIX 4.2-4.5 


255 
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Operating System J 


IF .TTL on ICMP datagrams 
• -In Reply 


IP TTL on ICMP datagrams 
- In Req v - 


OpenVMS v7.1^2 


255 




Window? 95 


32 


32 


Windows 98 


126 


32 


Windows 96 SE 


128 


32 


windows ME 


128 


32 


Windows NT 4 WRKS SP 3 


129 


' 32 


Windows NT 4 WRKS SP 6a 


128 


32 


Windows NT 4 Server SP4 


128 


32 


Windows 2000 Professional 


126 


128 


Windows 2000 Server 


128 


128 i 



Table 6: IP TT1_ Field Values in requests from Various Operating Systems 



The ICMP Query message type used was ICMP Echo request which is common on all operating 
systems tested using the ping utility. 



- LINUX Kernel 2.0.x, 2.2j< & 2.4.x use 64 as their IP TTL Field Value with ICMP Echo 
Requests. 

• FreeBSD4.1. 4.0, 3.4; Sun Solaris 2.5.1, 2.6, 2.7, 2.8; OpenBSD 2.6, 2.7, NetBSD and 
HP UX 10.20 use 255 as their IP TTL field value with ICMP Echo requests. With the OSs 
listed above the same IP TTL Field value with any ICMP message Is given. 

• Windows 95/98/98SE/ME/NT4 WRKS SP3 1 SP4,SP6a/NT4 Server 5P4 - all using 32 as 
their IP TTL field value with ICMP Echo requests. 

• A Microsoft window 2000 is using 128 as its ip TTL Field Value with ICMP Echo 
requests. 



We can distinguish between LINUX, Microsoft Windows 2000, the other Microsoft operating 
systems group, and the "255 group" using this method. 



6.3.3 Correlating tho Information 

Using the IP TTL field value with ICMP messages we can distinguish between Microsoft Windows 
.2000, certain Microsoft Windows Operating systems, UNUX Kernel 2<2.x & 2.4jc, LINUX Kernel 
2.0.x, and the *BSD and Solaris group. 



Operating System 


IP TTL vahjfeJn the ECHO Requests 


IP TTL value In the ECHO ftepfess 


Microsoft Windows Family 


32 


128 


•BSD and Solaris 


255 


255 


UNUX Kernel 2J2jc & 2 Ax 


64 


255 


LINUX Kernel 2.0* 


64 


S4 


Microsoft Windows 2000 


128 


126 


Microsoft Window? 95 


33 


32 



Table 7: Further dividing the groups of operating systems according to IP TTL field value In the ICMP ECHO 

Requests and in the ICMP ECHO Replies 
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One would expect that the IP TTL field value would be the same with both ICMP Query requests 
and ICMP Query replies. Apparently this is not true and provide us with valuable Information 
about the operating system querying / being queried. 



6,4 Using Fragmented ICMP Address Mask Requests (Identifying Sun Solaris & 
HP-UX 1-LOx machines) 3 * 

It appears that only some of the operating systems would answer an ICMP Address Mask 
Request as it is outlined in Table 2 in section 2.5. Those operating systems include - ULTRIX 
OpenVMS, Windows 95/93/98 SE/ME, NT below SP 4, HP-UX 11. Ox and SUN Solaris, How can 
we distinguish between those who answer the request? 

This is a regular ICMP Address Mask Request sent by SING to a SUN Solaris 2.7 machine: 

[root@aik iemp]# ./sing -mask IP_ Address 

SINGing to IP_Address (IP_Add:ress) r 12 data bytes 

12 bytes £rom~IP_Addre&8 : iernpseq-0 ttl-236 maek=25 5, 255.255. Q 

12 bytes from IP_AddresS: icmp_seq=l tnl-236 TnaBk=255.255,25S. 0 

12 bytes £ron» lP_Address: icmp~B,eq^2 ttl=236 mask=2SS .255-255. 0 

12 bytes from IP_Addresg: icinp_seq»3 ttl«=236 maek=255 • 255 . 255 . 0 

12 bytes from IP_Addxess : icirtp_eeq=4 ttX=23G mask-255.255.255. 0 

IP_Address sing statistics 

5 packets, transmitted, 5 packets received, 0% packet loss 

All operating systems that would answer with ICMP Address Mask Reply would reply with the 
Address Mask of the network they reside on. 

What would happen if we would introduce a little twist? Lets say we would send those queries 
fragmented? 

In the next example, I have sent ICMP Address Mask Request to the same SUN Solaris 2.7 box r 
this time fragmented to pieces of 8 bytes of IP data. As we can see the answer I got was unusual: 



[rootOaik icmp] # ./sing -mask -c 2 -F 8 IPJAddress 
$HTGing to iPJkddress (IP_Addreao) z 12 data bytes 
12 bytes from I*_Address; icmp_seq=0 ttl=24l mask=0. 0.0*0 
12 bytes from IP_Addressi icmp_Beg=al ttl=241 mask=0. 0.0.0 

IP_AddxreBS sing statistics 

2 packets transmitted, 2 packets received, 0% packet loss 
[ro'otOaik icrap]# 

The tcpdump trace: 

20 s 02 s 46 .441174 pppO > y-y-Y-Y > Host_Address : icmp: address mask 
request (frag 13170+ B@0+) 

4500 001C 3372 2000 ffOl SQab yyyy yyyy 
xxxx 1100 aee3 401c 0000 
20:02:4B.44265B pppO > y.y .y.y > HOSt_Address-. (frag 13170;4@8) 

4500 0018 3372 oooi ffoi 7oae yyyy yyyy 

3aaoc xxxx 0000 0000 



The Solaris portion was also discovered by Alfredo Andres Croatia. 
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20:02c49. 111427 pppO < Host_Address > y-y.y.y: icrap: address mask is 
0x00000000 (OF) 

4500. 0030 3618 4000 flOl 3C01 xaooc aoexx 

yyyy yyyy 1200 401c 0000 0000 0000 

20:02 :49.44l49i pppO > Y*Y*Y*Y > Host_Addree© : lamp: address mask 
request (frag 13170: 8G0+) 

4500 001c 3372 2000 ffol 50ab yyyy yyyy 

xaoOC xjooc 1100 ade3 401c 0X00 
20:02:49.442951 pppO > Y*Y*Y*Y > HoSt_Addresi5 ? (frag 13170:40$) 

4500 0018 3372 0001 ffiOl 70ae yyyy yyyy 

3QQOC »OC3t 0000 0000 
20 1 02 1 50. 011433 pppO < fiost_Address > y*Y*Y-y = icmp: address mask is 
0x00000000 (DP) 

4500 0020 3619 4000 flOl 3CO0 xxxx. xxxx 

yyyy yyyy 1200 ace.3 401c 0100 0000 0000 

The same SUN Solaris box now replies with a 0.0.0.0 as the Address Mask for the Network it 
resides on* The same behavioral patterns were produced against an HP-UX 11. Ox operating 
system based machine 35 . 

What would happen with the other operating systems? 

They all would respond with the real Address Mask in their replies. 

Here we got a distinction between SUN Solaris & HP-UX 1 1 .Ox based machines to the other 
operating systems that would answer those queries. 

In Section 6,2 we were discussing the various issues regarding the DF Bit usage within the ICMP 
Query replies. Both. SUN Solaris and HP-UX 1 1 .Ox set the DF Bit by default In their ICMP Query 
replies. HP-UX 11. Ox based machines starts setting the DF Bit after they finishes the ICMP based 
PMTU Discovery process (Querying the Host that has queried them with ICMP Echo request) - if 
it is enabled by default. This gives us another means to distinguish between those two operating 
systems on top of another method. 

We can further try to distinguish between the remaining operating systems. This, if we would use 
the !=0 code method I am going to introduced in section 6.6: 

Important notice : When I have tested this method ! have encountered some problems repBcating 
the results with different ISPs, As it seems from analyzing the information I got, certain ISPs 
would block fragmented ICMP datagrams. This behavior would not enable this method to 
succeed* One way of testing this Is to send a regular ICMP Echo request We should watch for a 
response from the probed machine. If received, than we should send ICMP Echo request, this 
time fragmented. If no reply is received than your ISP is blocking ICMP fragments probably. 



36 When I have published this information in Bugtraq (August 5. 2000) Peter ^ L^^.Ih!^^ 
□roduce the same behavior as the SUN Solaris boxes. Darren Reed also noted the* because SUN solans and hp-ux 
11 0 share the same thW party (Mentat) implementation for soma of their TCP/IP stacks this behavior Is produced by 
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1CMP Address Mask Request 

0 

Reply / \ No Reply 



Sun Solaris 
HP-UX 11. Ox 
UltrixOpenVMS 
Windows 95/99/98 SE/MT Below SP 4 



Other OS's 



ICMP Address Mask Request Fragmented 



Reply with 0.0.0,0 




Sun Solaris 
HP-UX 11. Ox 



• Reply with the 
same Address 
Mask as In Step 1 



Ultrix OpenVMS 
Windows 95/98/98 SE/NT Below SP 4 



(3) ICMP Address Mask Request 
with Code field M) 



Reply with code-0 



Reply with code!*0 



Windows 95/98/98 SE/NT Below SP 4 Ultrix OpenVMS 



Diagram S: Finger Printing Using ICMP Address Mask Requests 



Using Crafted ICMP Query Messages 



Playing with the TOS Field 

Each IP Datagram has an 8-bit field called the TOS Byte", which represents the IP support for 
prioritization and Type-of-Service handling. 



Precedence 



TOS 



MBZ 



Figure 1 1: The Type of Service Byte 
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. The TOS Byte" consists of three fields. . 

The "Precedence field", which is 3-bit long, is intended to prioritize the IP Datagram. It has eight 
levels of prioritization 36 ; 



Precedence 


Definffiori 


0 


Routine (Normal) 


1 


Priority 


2 


lifi mediate 


3 


Flash 


4 


Rash Override 


5 


Critical 


6 


Internetwork Control 


7 


Network control 



Table 8: Precedence Field Values 



Higher priority traffic should be sent before lower priority traffic. 

The second field, 4 bite long, is the Type-of-ServIce' field. It Is Intended to describe how the 
network should make tradeoffs between throughput, delay, reliability, and cost In routing an IP 
Datagram, 

RFC 1349 37 has defined the Type-of-Servfce" field as a single enumerated value, thus 
interpreted as a numeric value rather than independent flags (with RFC 791 the 4 bits were 
distinct options, allowing combinations as well). The 4 bits represents a maximum of 16 possible 
values. 



Value (Hetf. 


Value (Dec)i 


Value (Binary) i 


Service 


0 


0 


OOfJO 


Normal 


1 


1 


1000 


Minimize Delay 


2 


2 


0100 


M&xfmfee Throughput 


4 


4 


0010 


Manmfza Reiiabflfty 


0 


6 


0001 


Minimize Cost 


F 


15 


1111 


Maxlm&e Security" 



Table 9: Type-of-Servics Field Values 



What about the other 10 value possibilities? 

RFC 1 349 refer to this issue and states that "although the semantics of values other than the five 
listed above are not defined by this memo, they are perfectly legal TOS. values, and hosts and 
routers must not preclude their use in any way\./A host or a router need not make any 
distinction between TOS values who's semantics are defined by this memo and those that are 
nor. 



36 RFC 791 - Internet Protocol. hrtp;/Awww,fetf-om/rfcAfc791 .bet 

37 RFC 1349 - Type of Service in the internet Protocol Suite, r^!//wvyw ietf.org/rfc/rfc1 349.txt_ 

38 RFC 1455 - Physical Link Security Type of Service, http://uniwjejf.or^ 

60 

Copyright © OfTr ArUn, 2000-2001 

httD-7/www.svs^eevritv,cem 



898-d 60Z/MI d 6U-1 



302609261-61 



j eegyuos | q ' sue; j ' eqqouy-iuo j j uidjty : SO V0-06-9Q 



twM NOIIVMQ «Z0S60926M:aiSD «90C63Z8:SINa JHHXdJOldSflHAS «|muu. wWea UW^I Ndn:9Z:6 MiZflffill «8£mi 39Vd 

o n 

ICMP Usage in Scanning 



The last field, the "MBZ^must be zero), is unused and must be zero. Routers and hosts Ignore 
this last field. This field is 1 bit long. 

Combining Type-of-Service flags with the different prioritization values* dictates very explicit types 
of behavior with certain types of data. 

Please note the not all TCP/IP implementations would use this values (nor offer a mechanism for 
setting those values) and some will not handle datagrams which have Type-of-Servlce and/or 
Precedence values other than the defaults, differently. 



6.5 Precedence Bits Echoing (Fingerprinting Microsoft Windows 2000, ULTRIX, 
HPUX 11.0&10.30, OpenVMS and more) 

The precedence bits behavior is a problem. RFC 1 122, which defines the requirements for 
Internet Hosts, does not outline the way to handle the Precedence Bits with ICMP. The RFC only 
statement about the Precedence Bits is: 

The Precedence field is Intended for Department of Defense applications of the Internet 
protocols. The use of non-zero values in thfe field is outside the scope of this document 
and the IP standard specification. Vendors should consult the Defense Communication 
Agency (DCA) for guidance on the IP Precedence field and its implications for other 
protocol layers. However, vendors should note that the use of precedence will most likely 
require that its value be passed between protocol layers in just the same way as the TOS 
field is passed". 

This does not give us something to work with. 

RFC 1 812, Requirements for IP version 4 routers state that: 

"An ICMP reply message MUST have its IP Precedence field set to the value as the IP 
Precedence field in the ICMP request that provoked the reply*. 

Echoing back the Precedence field value has its logic, because the TOS field should be echoed 
back with an ICMP Query replies, and both the Precedence field and the TOS field were to 
dictate very explicit types of behavior with certain types of data. 



As you can see we do not have a clear ruling about this issue. I was thinking it might be a ground 
for an operating system fingerprinting method. 

Most operating systems I have checked will behave as the next behavioral example with A1X 4.3. 
With this example an ICMP Echo request is sent which carries a value for the TOS field. 



[root@godfather precedence_ecbo] # /usr/ local/bin/ sing -e 5 

y-y-y-y 

SINGing CO Y-Y-Y*Y <Y.Y-Y-Y> = * 6 data *>Yt es 

16 bytes from y.y.y^ seq-0 ttl-239 txme~5896 . 472 ms 

16 bytes from y.y.y.y: seq-1 ttl-239 TOS-128 time*5952 . 071 ms 

16 bytes from y.y.y-y: seq-2 ttl-239 T0S-X28 M-61M.020 me 

16 byte* from y.y.y.y: *«r=3 ttl-239 TOS=12fi tx«e*«261. M7 ms 

16 bjtes fromy.y.y.y: seq«4 ttl-239 TOS-X2S t±me=5842. 726 ms 

y.y.y »y sing statistics 

5 packets transmitted. S packets received, 0% packet loss 
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round- trip miii/avg/max = 5842 .726/6011 .057/6261, 997 ms 
[root&godfatber precedence_echo] # 

The tcpdump trace: 

23.; 02: S3 .241666 pppO > • > Y-Y^Y+Y 1 icntp: ecbo request [too 0x80] 

{ttl 255, id 13170) 

4580 0024 3372 Q0O0 ffOl 619c xxxX xxxx 
yyyy yyyy 0800 c27B 6f05 0000 dd97 0d3a 
d8af 0300 

21:02:59.134297 pppO < y.y.y-y > X-x.x.x- icrnp: echo reply [tos 0x80] 
(ttl 239, id 4065G) 

4580 0024 9edo oooo ©foi 063e yyyy yyyy 

XXXX xxxx 0000 ca78 6f05 0000 dd97 0d3a 

. dsaf 0300 

The Host queried is using the value used for the ICMP Echo Request with Hs ICMP Echo Reply- 
Some operating systems are the exception. 

The next example is with Microsoft Windows 2000. The same ICMP Echo Request was sent 
[root<9godfather precedence_echo] # /usr/ local/bin/ sing -c 5 -TOS 126 

y-y-y-y 

siNGing to y.y~y-y <y-y*y-y) = is <*ata bytes 
16 bytes from y*y-y.y= seq=o ttl-iil TOS=o time-6261 .043 ms 
16 bytes from y.y.y.y: seq=l ttl-m *rOS=0 time»6422 ,019 ms 
X6 bytes from y.y*y-y: seq=2 ttl»lll tos=0 time*=6572 .675 ms 
1€ bytes from y.y.y.y; seq=4 ttl=lll TOS=0 time-6282 .022 ms 

1 y-y-Y'Y sing statistics 

5 packets transmitted, 4 packets received, 20* packet loss 
round-trip min/avg/max = 6261.043/6384.440/6572.675 mS 
[root®godf ather precedence_echo3 # 

The tcpdump trace: 




20:13;36. 717070 pppO > x.x.x.x > y.y.y.y: icmp: ecbo request [tos 0x80] 
(ttl 255, id 13170) 

4580 0024 3372 0000 ffOl d95d xaoex xxxx 

yyyy yyyy osoo d*43 0304 oooo sosc od3a 
edfO OaoO 

20x13:42.974295 pppO < Y-Y-Y-Y > x.x.x.xs icmp: echo reply (ttl 111, id 
26133) 

4500 0024 6615 oooo 6fol 373b yyyy yyyy 
XX3DC xxxx 0000 e743 c304 0000 508c 0d3a 
edfo OaOO 

The ICMP Echo Reply will not use the value assigned to the Precedence Bits with the ICMP Echo 
Request. 

Which operating systems share this behavioral pattern? Microsoft Windows 2000 Family, and 
ULTRIX. 
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Differentiating between Microsoft Windows 2000 and Ultrix is easily achieved if we examine the 
IP TTL field value. With ULTRIX the value assigned to the 1CMP Echo reply will be 255. with 
Microsoft Windows 2000 it win be 123. 



Another interesting case is with HPUX 1 1.0. Lets examine the trace and logs: 

[rootGgodfather precedence_ecno] # /usr/local/bin/sing -c 2 -TOS 128 
y.y.y^y 

SXNGing. to y.y.y.y (y^y-y-y) * 16 d*ta bytes 

16 bytes from y.y.y.y: seq^O ttl=242 TOS=128 time=639.274 ma 
16 bytes from y.y»y-y* seq=l DF1 ttl=242 TOS^O time=3l0*427 niB 

y-y.y.y sing statistics 

2 packets transmit ted , 2 packets received, 0% packet loss 
round- trip min/avg/roax = 310.427/474.850/639.274 ms 

The first reply from the HPUX machine echoed back the TOS field value we were using with the 
ICMP Echo Request. But what have happened between the "first and the second reply? 

00:35 = 09.315260 pppO > x.x.x.x > y.y-y-y: icmp: echo readiest [toe 0x80] 
(ttl 255. id 13170) 

4580 0024 3372 0000 ffOl 4bdl xxxx xxxx 

yyyy yyyy o$oo isfo db3c oooo 9dc9. o<i3a 

56cf 0400 

00:35-09.944274 pppO < y.y.y.y > x.x.x.x: icmpt echo request (Dtf) (ttl 
242, id 22417) 

4500 osdc 5791 40oo f20i ef79 yyyy yyyy 

xxxx,xxxx 0800 7e52 9abc defO 0000 0000 
0000 OOOO 0000 0000 0000 0000 0000 0000 

0000 oooo oooo 0000 oooo oooo oooo 0000 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo- oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo ooao oooo 
oooo oooo oooo oooo .0000 oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooa oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
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0000 0000 0000 oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo ooop oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo OOOO OODO oooo 
oooo oooo oooo oooo qooq oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo opqo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oboo oooo oooo 
oooo oooo oooo oooo' oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo OOQD oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oopo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo OOOO OOOO OODO oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
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The first request was sent, as an instant reply the HPUX 1 1 .0 machine started te PMTU ^ 
discovery process with ICMP Echo Requests and sent an ICMP Echo Request 1500 bytes long . 



echo reply (ttl 255, id 



00:35:09.944355 pppO > x<x.x 
14194) 

4500 OSdc 3772 OOOO ffOl 4299 »odx: xxxx 

yyyy yyyy 0000 8652 9ai?c ^ ef0 0000 0000 

OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO oooo OOOO OOOO oooo OOOO 
OOOO OOOO OOOO OOOO oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo aooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo OOOO OOOO oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooooooo oooo oooo oooo oooo 

0000 0000.0000 0000,0000 oooo oooo 000.0 

oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo OOOO 
oooo oooo oooo OOOO oooo OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO oooo oooo oooo 

oooo oooo oooo oooo oooo oooo oooo oooo 

oooo oooo oooo oooo oooo oooo oopo oooo 

oooo oooo oooo oooo oooo oooo oooo oooo 

oooo oooo oooo oooo oooo oooo oooo oooo 



39 For an explanation about the HPUX 1 1 .0 PMTU process using ICMP Echo Requests please section 6-Z 
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OOOO 0000 0000 0000 .OOOO 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 oooo 

oooo 0000 oooo oooo oooo oooo 0000 oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo aooo oooo oooo 
OOOO oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo 0000 oooo 
□000 oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo / 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo 0000 0000 000.0 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo .0000 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo* 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo/oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
' oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo- oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
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oooo oooo oooo oooo oooo oooo 00.00 oooo 
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0000 0000 OD0O 0000 0000 0000 

00:35:09.954282 pppO < y.y* Y-Y > XvX.x.Xi icmp: echo reply [tod 0x80) 
(ttl 242, i<i 22418) 

4580 0024 5792 oooo f20i 34bi yyyy yyyy. 

xxxx xxxx 0000 le£0 db3c 0000 9dc9 0d3a 
56cf 0400 



The ICMP Echo Reply received from the HPUX 1 1 .0 machine for the ICMP Echo Request 
echoed back the TOS field value. 

Another ICMP Echo Request was sent with TOS field value of 0x80 hex: 

00i35:10, 314321 pppO > x.x.X.X > Y-Y-Y-Y: icmpi echo request [too 0x00] 
(ttl 255, id 13170) 

4560 0024 3372 0000 ffOl 4bdl XXXX XXXX 
yyyy yyyy 0800 b7f3 <3b3a 0100 9ec9 0d3a 
b3cb 0400 

00:35:10.624275 pppO < y.y.y.y > X*X.x.x = iamp: echo reply (DP) (ttl 
242, id 22419) 

4500 0024 5793 4000 £201 £52£ yyyy YYYY 
xxxx xxXX 0000 bff3 db3c 0100 9eC9 0d3a 
b3cb 0400 

The ICMP Echo Reply received did not echo back the TOS field value, and set the DF bit The 
PMTU discovery process finished Us initial stages and went to regular operation. From now on 
the ICMP Echo Replies did not echo the TOS field value. 

This gives us the ability to track down HPUX 11 .0 (and 10.30) machines when they are using the 
PMTU Discovery process. 

6,5.1 Changed Pattern with other ICMP Query Message Types 

We can identify change of pattern with OpenVMS r Windows 98, 98SE, and ME. With ICMP Echo 
replies they all would echo back the TOS field value, but with ICMP Timestamp replies they will 
change the behavior and send back 0x000. Since OpenVMS use 266 as Its IP TTL field value, 
and the Microsoft Windows based machines use 128, we can differentiate between them and 
isolate OpenVMS, and the Microsoft based OSs. 

Further distinction between the Microsoft operating systems can be achieved if we wfll query 
them with ICMP Address Mask request, which only Microsoft Windows 98/98SE will answer for. 
The Microsoft Windows ME will not reply, enabling us to identify it 
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ICMP Echo Bequest 
Precedence Bite t=0 



© 

Reply with 
Precedence 
Bits 1=0 



fleply with 
Precedence 
BUb=0 



Other OS'S 

® ICMP Times tamp Request 
Precedence Bits W> 



Reply with 
Precedence 
BHS^O 




Other OS's 



Windows 200 D Family 
Ultrix 



TTL=265 



mtnx 



TTL=128 



Wlndows2000 Family 



WindOW£9e/9$SE/ME 
Op on VMS 
ULTRDC (fcentifled already) 
Microsoft Windows ZOOO Family 
(Identified Already) 



TTL=256 



OpenVMS 



Windows 98/&BSE/MH. 
©ICMP Address Mask Ffcquest 



No Reply 



ftapjy 



Windows ME 



Windows 9N9BSE 



Diagram 6: An example for a way to fingerprint Microsoft Windows 2000, Ultrix, HPUX 11 ,0 & 1050. 
OpenVMS, Microsoft Windows ME, and Mcrosoft Windows 98/98SE based machines with ICMP Query 
messages with the Precedence Bits field !=0 
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Operating isystem 


tnforrndfion 
Request 
Wftrv 
Precedence f=0 . 


r»me Stamp 
Request 
With Precedence!^ 


Address Mask: 
Request 1 
With Piecedencelwrj 


:echo Request . 
With pracedencel-0 
• 


Detfan GNU/ LINUX Z^, 
Kamd Z4 test 2 
Redhat LINUX 6.2 Kernel 
2.2.14 

FreeBSD4.0 
FreeBSO 4.1.1 
OpenBSD2.7 
OpenBSD 2.6 
NotBSD 

BSDIBSDfQ$4_0 


Not Answering 
Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 

1=0x00 
MfcOO 


Not Answering 
Not Answering 

Mot Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 
1-0x00 

1=0x00 

1=0x00 
1=0x00 
1=0x00 
1=0x00 
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Operating System 


Information : 
:Re6,wst. •* 

With ;- 

Precedence! s^o • .1 


Time Stamp ■ 
Request ' . 
..Wltn Precedencel=0 

r • 


Address Mask 
Request . 
WUh Precedence*^ 


. Echo Request 
With Precedence!^) 


dSLjI «»l 


Not Answering 




Not Answering 


1=0x00 


Solaria 2.5.1 
Solaris 2.6 
Solaris 2.7 
Solaris 2-B 


Not Implemented 
Not Implemented 
Not Implemented 
Not Implemented 


1=0x00 
1=0x00 
1=0x00 


!=0x00 

laOxOO 

1=0x00 


I— UXUU 

1=0x00 
1=0x00 


HP-UX v1 020 ! 
HPAJXvH-0 | 


Not Answering 


Not Answering 


Not Answering 
! -Qx00-> OxDO 


t=0x00 -» OxDO 


Compaq Tru64v5-0 


1=0x00 


*=Ox00 


Not Answering 


1=0x00 


AIX4.3 
NX 4.2.1 
AIX4.1 * 
ADC3.2 


1=0x00 
t=0x00 
1 1-0x00 
■: 1=0x00 


1=0x00 
1=0x00 
1=0x00 
!=Qx00 


Not Answering 
Not Answering 
Not Answering 
Not Answering " 


!=0x00 
1=0x00 
1=0x00 
1-0x00 


ULTR1X 4*2-4.5 


0x00 


rjxoo 


0x00 


0x00 


OpenVMS v7.1-2 


0x00 


0x00 


0x00 


1=0x00 


Windows 95 

Windows 9B 

Windows 96 S£ 

Windows ME. 

Windows NT4 WRKS SP 3 

Windows NT 4 WRKSSP 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x00 

0x00 

0x00 
Not Answering 
NotAnswerino 


0x00 
0x00 
Not Answering 

Not Answering 


1=0x00 
1=0x00 
1=0x00 
1=0x00 
1=0x00 


6a 

Windows m 4 Sewer 5P4 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
0x00 
0x00 


Not Answering 
Not Answering 
Not Answering 


1=0x00 
0x00 
OxDO 



Table 10: ICMP Query Message Types with Precedence Bits I =0 



6.6 TOSing OSs out of the Window / "TOS Echoing" (Fingerprinting Microsoft 

^V¥E S JeSlhe Type-of-Servic* field with the Internet Control Message Protocol 

RFC 1349 Sso define lhe usage of the Type-of-Service field with the ICMP messages Jt 

Redirect, Time Exceeded, end Parameter. Problem). ICMP query messages < e ^°« „ 
SoBdtatton, Timestamp. Information request, Address Mask ^^f^JT^^T 
(Echo reply. Router Advertisement, Timeslamp reply, Information reply. Address Mask reply). 

Simple rules are defined: 

- An ICMP error message is always sent with the default TOS (0x00) 

p An irMP reouest message may be sent with any value in the TOS field. "A mechanism to 
S ! !£3 S TOS value to be used would be a useful feature In many 
applications that generate ICMP request messages . 



40 RFC 1349 -Type of Service in the Internet Pmtocrt S ^ArV^y" M OT^rfglfrtS.ftt . 
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The RFC further specify that although ICMP request messages are normally sent withthe 
default TOS, there are sometimes good reasons why they would be sent with some other 
TOS value. 

* An ICMP reply message is sent with trie same value in the TOS field as was used in the 
corresponding ICMP request message. 

Using this logic I have decided to check rf certain operating systems react correctly to '™P 
Query messages with a Type-of-Service field value, which is different than the default (0x00). 

The check out was produced with all ICMP query message types sent with a Type-of-Servfce field 
set to a known value, than set to an unknown value (the term known and unknown are Used here 
because I was not experimenting with non-legit values, and since any value may be sent Inside 
this field). 

The following example is an ICMP Echo request sent to my FreeBSD 4.0 machine with the TOS 
field equals an 8 hex value, which is a legit TOS value. The tool used here is SING : 

[rootegodfather bin]# ./sing -echo -TOS 6 rP_Addrese 
STNGing to XF_Address <IP_Atfdress) = 16 data bytes 

16 bytes from IP_Addr*ss: icmp_seq=2 ttl-243 TOS=fi tiroe=260.043 ms 

16 bytes from IP Address: icrnp_ S e<i=3 ttl-243 TOS-8 time- 18 0.0 11 me 

16 bytes from IP^Address: icmp_3eq-4 ttl=243 ti*e»24Q . 240 ms 

16 bytes from IP^Address: icmp_seq=5 ttl=243 TOS-8 time=2S0 . 037 ms 

16 bytes from IP_Address: icmp_seq=6 ttl-243 *0S,=8 t±me=2?0 . 033 ms 

IP Address sing statistics 

7 packets transmitted, 5 packets received, 28% packet loss 
round-trip min/a^g/max - 130 . 011/246 . 073/290 -033 ms 
[root®godfatber bin]# 

The tcpdump trace: 

17:23:46. eOS297 if 4 > x.x.x.x > y.y.y.y: iemp; echo request ttos OxSJ 

(ttl 255, id 13170) 

450fi 0024 3372 0000 ff 01 60e4 xxxx aocxx 

yyyy yyyy osoo-OeSa d604 oeoo £2ea bc39 

17,23:46.895255 if 4 < y.y-Y.y > X.X.X-x: icmp: ecno reply [to* 0x81 
(ttl 243, id 5Q832) 

4508 0024 esao oooo f30i ba85 yyyy yyyy 

xxxx XXXX 0000 169a d$04 0*00 f2e& bc39 
553C 0900 

This is the second test I have produced, sending ICMP Echo request «ith the , Typ*of-Service 
field set to a 10 Hex value, a value that is not a known Type-of-Servlce value. 



* 1 SINGha^he *«y to monftorfor any and than prints received TOS value. I tine thfe option vcyusef* and 



Oiiiunaa u«» t^—^j *~ »■ — — » ^ r — * -~r 

thank the author for embedding this function, as t requested^ 
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[rootogodfather bin]# ./sing -echo -*OS 10 lP_Address 
SlNGing to IP_Address (IP_Addreas) r Iff data bytes 

16 bytes from IP_Address: icnrp_seq=o ttl=243 tos^IO time«i97.933 ms 
16 bytes from IP_AddreSS: icrap seq=i ttl^243 TOS»10 time=340.04B ms 
16 bytes from IP Address: icmp_Beq=2 ttl-243 T0S-10 time=250,025 ms 

15 bytes from IP_Addrees: icmp_seq=3 ttl-243 TOS-10 time-230.019 ms 

16 bytes from lP_AddresS; icrap_eeq=4 ttl-243 tfOS=10 time«^27Q , 017 ms 
16 bytes from IP_Address: icmp_seq»5 ttl=243 TOS=10 time-270.017 ms 
16 bytes from IP_AddresS ; icmp_seq=6 ttl-243 TOS=10 time~260 . 021 ms 

IP_Address sing statistics 

7 packets transmitted, 7 packets received, 0% packet loss 
round-trip min/avg/max - 197 . 933/2S9 .726/340 . 048 ms 

The tepdump trace: 

17:24i36.155298 if 4 > y.y>y.y > X.x.x.x: icmp: echo request [toil 
0xa,ECT] (ttl 255, id 13170) 

450a 0024 3372 oooo ffoi 60e2 yyyy yyyy 

xxxx aaotx 0800 af77 d904 O600 24eb bc39 
865e 0200 

17:24:36.415254 if 4 < X.X.X.X > y.y.y.y: icmp: echo reply ItoS 
0aca,ECT] (ttl 243, id 65031) 

450a 0024 fe07 0000 £301 a24c xxxx xxxx 

yyyy yyyy oooo b777 d904 osoo 24eb bc39 

865e 0200 

As it can be seen from the tepdurnp trace, the ICMP Echo reply messages have maintained the 
Type-of-Service value as was used in the corresponding ICMP request message* 

FreeBSD 4.0 does not respond to ICMP Information request, or to ICMP Address Mask requests. 
1 had to verify with ICMP Tlmestamp requests with the same Type-of-Seryipe values as with the 
previous ICMP Echo requests that this behavior is produced with ICMP Tlmestamp request and 
replies as well. 

Again the tool I have used is SING: 

[rootogodfather binjtf ./sing -tatamp -TOS a iP^Addresa 

SItfGing to IP_Addxas S UP_Addre*s) z 20 data bytes 

20 bytes from IP^Address* icmp^eq^O ttl^243 T0S-8 

20 bytes from IP.Address: icm P _ S eq=l ttl-243 *OS~a ^«-«"4M 

20 bytes from IP Address: icmp_seq-2 ttl-243 V06-8 ^«=""M3 

20 bytes from IPlAddrecs; icmp_^eq=3 fctl^3 .WM 

20 bytes from IPJtidntfli icitrp^sea-4 ttl-243 dif£ -6832431 

--r IP Address sing statistics 

5 packets transmitted/ 5 packets received, 0% packet loss 
[rootftgodfatber bin]# 
The tepdurnp trace: 

17,2^:00.455295 if 4 > x.x.x.x > y.y.y.Y: icmp: time stamp request 
TtoS 0x8] (ttl 255, id 13170) 

450B 0028 3372 0000 ffOl 60e0 xxxx XXXX 
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yyyy yyyY OdOO 345b dd04 0400 0318 da87 

. 0000 0000 0000 0000 

17=26:00.755254 if 4 < Y-Y-Y-Y > *x.x.Xt icmp: time stamp reply [tOfl 
0*fll (ttl 243 f id 5567) 

4508 0028 lfieb 0000 £301 6967 yyYY YYYY 

xxxx 0e00 f4ec dd04 0400 031S da67 

0380 lbb7 O3$0 lbb7 

The second test with TOS field value set to 10 Hex value: 



[rootegodfatHer bi*]# ./sing -tstamp 
SINGing to IP_Addrese <tP_Adcxess) ; 2 
20 bytes from IP_Address: icmp_seq=0 
20 bytes from iP_Address : icmp_seq;=l 
20 bytes from IP_Address: icmp_seq«2 
20 bytes from IP_Address : icinp^seq^? 
20 bytes from XP_Address: icmp_seq=4 
20 bytes from IP_Address: icmp_seq*=5 
20 bytes from IP^Addreas : icmp_ee*j-6 
20 bytes from IP_Address: icnrp^ eeq=7 



TOS 10 IP_Addrese 
0 data bytes 

ttl=243 T0S=10 diff=>6766872 
ttl«243 TOS=l0 diff -6767059 
ttl^242 TOS-10 diff-6767055 
ttl=243 TOS^IO diff^67«7063 
ttl=243 TOS=10 diff=G766892 
ttl»243 TOS-10 diff =6765887 
ttl=243 TOS«10 diff-6766873 
ttl=243 TOS^IO di€f««fi767057 



194.47.250-37 Bing statistics 

9 packets transmitted, 9 packets received, 0% packet loss 
[rootfcgodf ather bin] # 



The tepdump trace: 

17:25:42:548597 if 4 > x.x.x.x > y.y.y.Y: icmp: time Stamp request 

ttoo 0*&,£CT] (ttl 25*, id 13170) 

450a 0028 3372 0000 ff 01 fiOde *xxx xxxx 

yyyy yyyy 0d00 7f4e dc04 0000 0318 9494 

0000 0000 0000 0000 

17:25:42.795254 if 4 < y-y-y-V > x.x.x.xt icmp: time stamp reply Itoa 

0x*,I3C*] {ttl 243, id 3519) 

450a 0028 Odbf 0000 f30l 9291 yyyy yyyy 

auooc X3UCX OeOO ebf<? dc04 0000 0318 9494 

037f d5ac 037f dSac 

The same behavior was produced. The ICMP Timestamp replies were sent with the TOS field 
value equals the TOS filed value of the ICMP Timestamp requests. 

Ok: I was curious again. I Imagined that the Microsoft Windows implementation of the things 
might be a little different 

When I was examining ICMP Echo requests I noticed something is wrong with Microsoft 

irootagodfather bic]# ./sing -echo -TOS B Host Address 

SXNGing to Hosted**** <*?-^*^ ms 

16 bytes from IP_Address: icmp_seq=0 ttl-113 TOS-0 ™ 

16 bytes from IP_Address: icmp^seqd ttl-113 TOS=0 time-239 . 935 ms 
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16 bytes from XP_Address: icrap seq-2 ttl=113 TOS-0 time=249.937 ins 
16 bytes from IP Address; icm P- seq=3 ttl=H3 TOS=0 tirae=229 . 962 ras 
IS bytes from XP>ddxess: icrap_seq a 4 ttl=113 TOS-0 time=249. 951 ns 

Host_Address sing statistics — 

5 packets transmitted, S packets received. 0% packet loss 
round-trip min/avs/«ax - 229-962/249.720/278-813 ms 
[root®godfather bin]# 

The tcpdurnp trace: 

17:28:08.346537 if 4 > x.x.x.x > y.y. Y-Y = icrap. echo request Etc* 0x8] 
(ttl 255, .id 13170) 

4508 0024 3372 0000 f£01 0S3£ xxxx xxxx 
yyyy yyyy 0800 Cd8b e704 0000 f8eb bc39 
8949 0S0O 

17:38:08.625250 if 4 < Y-Y-Y-Y > x.x.x.X: icrap: echo reply (ttl 113, 
id 12351) 

4500 0024 3297 Q000 7101 9722 yyyy yyyy 
xxtfx xxxx 0000 d5Bb e704 0000 f8eb bc3$ 
8949 0500 



Oops! Some one zero out my Type-of-Service field! 

Before I would let you know who of all Microsoft Windows operating systems did that, tarn going 
to list the Microsoft operating systems who behave correctly - Microsoft Windows 98/SE/ME, 
Microsoft Windows NT 4 Workstation SP3, Microsoft Windows NT 4 Server SP4, Microsoft 
Windows NT 4 Workstation SP6a. 

The Microsoft Windows 2000 family (Professional, Server, Advanced Server) zero out this field on 
the ICMP Echo reply. 

Is this makes those Microsoft Windows 2000 machines identified easily and uniquely? 
99.9% yes. The other 0.01 % betongs to Ultrix & Novel Netware. 

From the operating systems l have checked (Linux Kernel 2^, "nuxKemel ^2.4 ^*4*. 
FreeBSD 40 &4.1, OpenBSD 2.6 & 2.7, NetBSD 1 A2, SUN Solaris 2.7 & 2.8, COTpaq Tni64 
SS 5S A* 4.1 k sS OpenVMS v7i Irix 6.6.3 & 6.5.8, UIWx 4*44 ^^indo^ 
oa/sp/ME Microsoft Windows NT 4 Workstation & Server with various service packs, Microsoft 
wiS Server &Advanced Server) only Uttrix & Novell Netware behaved 

like the Microsoft Windows 2000 machines. 

How can we distinguish between those? m . ' ihAn 

Rrst there are much fewer Ultrix and Novell operabng systems based mach^ out ^ere than 
Mlcraaffe Windows 2000 based machines (I see your faces - not convincing enough). 

The fast track in distinguishing between Ultrix. is * 

simple one. - By looking at the IP TTL field value wrthm ^ 

Windows 2000 family of operating systems use 128 as their default IP TTL flew value in i iwwr 
EWO^eplies whae Ultrix uses 255 the problem Is Novell uses the same value for its IP TTL 
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Field value as Microsoft Windows 2000 based machines (For more information about the IP TTL 
field value see section 6.3 - .The IP Time-to-Uve Field Value with ICMP"). 

As a next step we can use various types of queries in order to distinguish between the Novell 
Netware based machines, to the Microsoft Windows 2000 based machines. One of those steps 
can be an ICMP Timestamp request sent to the 'suspicious' machines. No reply from one of the 
machines will Indicate it may be using Novell Netware, a reply from a machine will indicate it te 
using one of Microsoft Windows 2000 operating system family product More sophisticated ICMP 
queries could replace the one 1 have introduced. 



Other ICMP query, message types help us to identify a unique group of Microsoft operating 
systems. As a rule all operating systems except the named Microsoft windows operating systems 
here, maintain a single behavior regarding the Type-of-Seivtee field. All would maintain the same 
values With different types of ICMP requests. But, again, Microsoft have some of the top people 
understanding TCP/I P to the degree we humans do not understand. 



iCMP&hoftoqtiftfit 
TOSM) 




TO8l=0 



Other OS'* 




Window 2000 Family 
IRbiX 
Novell htotwaiv 




TTL=255 



Windows 58«eSE/M£ 
Other OS's ULTRIX (identified Already) 

Windows 2000 Family (ktenUfldd 
Alnjady) 




No Reply 



Diagram 7: An example for a way to fingerprint Windows 2000. Ultrix, and NoveM Netware based machines 
with ICMP Query messages with the TOS bits field S=0 



We have the following Microsoft operating systems zero out (O^^eType^f^nnce field wrth 
the replies for ICMP Timestamp requests: Microsoft Windows 98/98SE/ME. Microsoft Windows 
2000 machines would zero out the TOS field with ICMP Timestamp replies as well. 

This means that Microsoft Windows 98/98SE/ME would not zero out the Type-of-Service field 

value with ICMP Echo requests but will do so with ICMP Timestamp requests. 

With the introduced fingerprinting methods In this section we got a way to fingerpnnt Microsoft 
Windows 2000 Uftdx andNovel Netware machines from the rest of the operate systems world. 
K away SfiSuhh Microsoft Windows 98/98SE/ME (and to set those apart) from the 
rest of the operating system world, as welL 
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Operating System 


information 
Request . t 
Wilh TOSl-OxOO 


Time Stamp Request 
WtthTpSl=©x00 


Address Mask 
Request 
WithTOSl=px00 


Echo Request . 
WiuiTOSIaOxOO 

■ ■ A 


Deblan GNU/ LINUX 2^, 

RedliatUNUX 62 Kernel 
2.2.14 


Not Answering 
Not Answering ' 


!=0x00 
1=0x00 


Not Answering 
Not Answering 


1=0x00 
1=0x00 


Freeeso 4.0 

rrBCDdU 

Open BSD 2.7. 
OpenESD 2.6 
Nettfou 

BSD1 BSD/OS 4.0 

ESDI D&UfUo 0*1 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Mnt AnswerinO 


1=0x00 

1=0x00 
1=0x00 
1-0x00 
1=0x00 
1=0x00 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1-0x00 

1=0x00 
1-0x00 
1=0x00 
1=0X00 
!=0x00 


soians z.t>. i 
Solaris 2.6 
Solaris 2.7 
Solaris 2.8 


Not Implftmenled 
' Not Implemented 
Not Implemented 
Not Implemented 


|=OxD0 
1=0x00 


1=0x00 
[oOxOO 


1=0x00 
1=0x00 


HP-UX v1 0.20 
HP-UX v 11.0 


Not Answering 


Not Answering 


Not Answering 
MfccQD 


1=0x00 


Compaq TruB4 v5.0 




1=0x00 


Not Answering 


1=0x00 


trix 6.5.3 
Iiix6.j5.ft 


Not Answering 
Not Answering 


1=0x00 
|=OxUa 


Not Answering 
Not Answering 


1=0x00 
!=0x00 


ADC4.1 

A IV "3 *1 

AJa 




1=0x00 
1=0x00 


Not Answering 
Not Answering 


1=0x00 
1=0x00 


UL7R1X4.2-4.5 




0x00 


OxOO 


0x00 


OpenVMS v7/l-2 




1=0x00 


1=0x00 


1=0x00 


Novell Netware SP1 
Novell Netware 5.0 
Novel Netware 3.12 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


0X00 
0x00 
0x00 


Windows 95 
Windows 98 
Windows 98 SE 
Windows ME 

Wfndows NT4 WRKS SP 3 
Windows NT 4 WRKS SP 6a 
Windows NT 4 Server SfM 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x00 

0x00 

0x00 
Not Answering 
Not Answering 
Not Answering 

0x00 

0x00 


0x00 

Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 


I=oxo0 
1=0x00 
1=0x00 
.1=0x00 
l-OxOO 
1=0x00 
0x00 
0x00 



Table 11: ICMP Query Message Types with TOS! - 0 

6.7 Using the TOS Byte's Unused Bit (Fingerprinting Microsoft Windows 2000, 

™M last flaw of the TOS byte, the W (must 

must tenro. The RFC also states that routers and hosts Ignore the value of this bit 

This is the only statement about the unused bit in the TOS Byte in the RFCs. The RFC states; 
"The originator of a datagram sets this field to Zero . 
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Obviously it was meant that this field would be always zero. But what will happen if we would set 
this bit with our ICMP Echo Requests? Win this bit be zero out on reply or win It be echoed back? 

Only with ICMP Echo requests we can have a clear Identification of OSs. 

The next example is an ICMP Echo Request sent with the TOS bit in the TOS Byte set, targeting 
a FreeBSD 4.1 ,1 machine: 

[root^godfather /root]# /us r/ local /bin/ sing -c % -TOS 1 y-y.y.y 
siUGing to y^y-y-y (y*y-y-y) = lfi d * ta bytes 

16 bytes from y.y.y*y= eeq=0 ttl-233 TOS-1 time-330*461 ma 
16 bytes from y.y.y.y: seq-l ttl=233 T0S=1 tlme=723.3Q0 ms 

— y.y.y^y sing statistics — 

2 packets transmitted, 2 packets received, 0% packet loss 
round- trip rain/avg/max = 33 0,461/526.860/723.300 ms 
[rootogodf ather /rootl # 

Echoing back the Unused bit in the TOS Byte, represents the behavior of most of the operating 
systems I have checked this method against 

Which operating systems are the exceptions? 

The next example is with Microsoft Windows 2000 as the targeted machine: 
[rootsgodfather p^ecedence^echol # /usr/local/bin/sing -c 2 -TOS 1 

y-y-y-y 

siNGing to y-y-y-y (y-y-y-y) 1 16 d * ta bytes 

16 bytes from y.y.y.y: seq=0 ttl«lll TOS-Q time-299 . IBS to* 
16 bytes from y-y-y-y; seg^l tti-m *os-o time-280*32l ras 

— y-y-y-y sing statistics — 

2 packets transmitted, 2 packets received, 0% packet loss 
round-trip min/avg/max = 280.321/289-755/299-188 ms 
IrootGgcdfather precedence^ cno) # 

The tcpdump trace: 

00 = 17x01.765492 pppO > x.x.x.x > y.y.y.y: icmpt echo revest ttofl 0*1] 
(ttl 255, id 13170) 

4501 0024 3372 0000 ffOl dS2b xxxx xxXX 

yyyy yyyy o 800 f ^ 15 7a3c 0000 5dc5 0d3a 
I7ae oboo 

00:17:02,064284 pppO * y.y.y.y > X.x.x.x: icmp: echo reply (ttl 111, id 

2 " 61) 4500 0024 7509 0000 6f 01 2696 yyyy yyyy 

xxxtl 3QCXX 0000 f815 7a3c 0000 SdcS 0d3a 
17ae 0b00 

Another OS that behaves the same is ULTR1X: ^^/»^« „ o -tos l 

lroot@godfather precedence^ cbo] # Just/ local /b^/sxng -c 2 -TOS l 

SiNGing to y.y.y-y (Y.y-y-Y) : " f^JZ?i\*^*n ins 
IS bytes from y.y.y-Y: ttl-237 TOS=0 tlTfte-371.776 ms 

v.v.y.y sing statistics 

2 packed transmitted, 1 packets received, 50* packet loss 
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round-trip min/avg/max » 371.7767371. "776/371 .776 ms 
[rootftgodf ather precedence_echo3 # 

Wo will use, again, the IP TTL field value to differentiate between the two operating systems. 

6.7.1 Changed Pattern with Replies for Different "CMP^eryType* 
We have a changed pattern with Microsoft Windows 9B/98SE/ME when using other ICMP Query 
Zt^ t^^Jth^ ICMP Echo Request Instead of echoing this field back, they Will zero 
out this field with their replies. 



ICMP Echo Request 
Unused BJt =1 



Reply wllh 
Unused Bit 1=0 




Other OS's 



® ICMPTimestAmp Request 
Unused Bit =1 



Reply with 

Unu»d Bit 1=0 



Other OS's 



Reply with 
Unused mt=0 



V Reply with 
Unused BH =0 



Windows 20DQ Family 
UlttfX 



TTL»255 



UltriX 



WJnd<?ws98/9&SEiME 
OpenVMS 
ULTRIX {Identified Already) 
WJndow* 2000 Family (Identified Already) 



TTL-128 



Window? 200 Q Family 



TTL=2S5 



TTL=128 



OpenVMS 



Windows 9 8/98 SE/ME 

©ICMP Address Mask Request 



Nq Reply 



Reply 



WindciwsME 



windows SB/daSE 



Diagram 8; An example for a way to fingerprint operating systems using the unused brtm theTOS Byte 

echoing method 



Further distinction between the Microsoft operating 2*^^^ 

them with ICMP Address Mask request which only Microsoft Windows 98/98SE will answer for. 

The Microsoft Windows ME will not reply, enabling us to identify it 
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Operating System* 

• J "j * ' * " 1 
' . »■ ■ • • - 


. Information 
■ .Request 
Vfrtti Unused=1 


Time Stamp Request 
. ' vyithUnuseo>l : r ' 


Address Mask 
: Request : " 
With Uhused=1 


Echo Request 
With UnusecVI 


Deblan GNU/ LINUX 2^, 
Kernel 2.4 test 2 
ttedhet linux 6.2 Kernel 
Z2.14 


Not Answering 
Not Answering 


0x1 
0x1 


MO i Answering 

Not Answering 


0x1 


Free6SD4.0 
FreefiSD 4.1.1 
OpenBSDZ7 
OpenBSD 2.6 
NetSSD 

BSD! BSD/05 4.0 
BSD! BSD/OS 3.1 


Not Answering 
Not Answering. 
Nat Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 ■ 
0x1 


■Lint AMcuMirinn 
fMQl /MISWct II iy 

Not Answering 
Not Answering 
' Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 
0x1 


Solans 2.5.1 
Solaris 2.6 
Solaris^ 
Solaris 2.B 


Nol Implemented 
Not Implemented 
Not Implemented 
Not Implemented 


0x1 
0x1 
0x1 


0x1 
0x1 
0x1 


0x1 
0x1 
0x1 


HP-UX v10.20 
HP-UX v1 1.0 


Not Answering 


Not Answering 


Not Answering 
0x1 


0x1 


Compaq Tru64 v5.0 


0x1 


0x1 


Not Answering 


0x1 


AIX4.3 
AIX4JL1 
AIX4.1 
AIX3-2 


0x1 
0x1 
Oxl 

0x1 


0x1 
0X1 
0x1 

Oxl 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


oxl 

0X1 

0x1 
0x1 


ULTRIX4.2-4.5 


0x0 


0x0 


! 0x0 


0x0 


OpenVMS v7.1-2 


0x1 


0x1 


0x1 


0x1 


Windows 95 
Windows 9ft 
Windows 98 
Windows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS SP 6e 
Windows NT 4 Server SP4 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x0 

0x0 

0x0 
Not Answering 
Not Answering 
Not Answering 

0x0 

0x0 


0x0 
0x0 

Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 
0x1 
0x1 

0x1 

0x0 
0x0 



Tabte 12: ICMP Query Message TYpes with the TOS Byte Unused Bit value 1 = 0 



6.8 Using the Unused (Identifying Sun Solaris & HP-UX 10-30 & 11-0x OS based 

EK? reiMTnas a three bits field used for various control flags In the IP Header. Bit 0 of this bits 
field is the reserved flag, and must be zero according to the RFC. 

What will happen if we will deckle to break this definition and send our ICMP Query requests with 
this bit set (haying the value of one)? 

Sun Solaris & HPUX 1 1-0x (possibly 10,30 as well) will echo back the reserved bit 

This is a tepdump trace describing an ICMP Echo request sent with the H ^ 
ICMP Echc ireply we received echoing the reserved bit. This trace was produced against an HP- 
UX 11 i0 machine: 

IB 
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21i31:21-033366 if 4 > Y-Y-Y-Y > x.x.x.X: ictnp: echo request (ttl 25S, 
id 13170) 

4500 O024 3372 6000 ffOl £cSc yyyy YYYY 
xxxx xxxx 0800 Bblb $603 0000 £924 bd39 
3062 0000 

21:31:21.317916 if 4 < x.x.x.x > Y*Y-Y-Y: ictnp: echo reply (ttl 236, 
id 25606) 

4500 0024 6406 8000 ecOl def 8 xxxx xxxx 

YYYY YYYY 0000 931b 5603 0000 £ ^ 24 bd39 . 
3082 0000 

The next trace was produced against a Sun Solaris 2-8 machine: 

16:51:37.470995 if 4 > 195.72.167.220 > X.x.x**: ictnp: echo request 
(ttl 255, id 13170) 

4500 0024 3372 8000 f fOl eOel C346 a7dc 
xxxx xxXX 0800 edae 3004 0000 69e3 bc39 
ad2f 0700 

16 = SI =37. 745254 if 4 < X.X.X.X > 195.72.167.220: icwp: echo reply (DF) 
{ttl 243, id 5405) 

4500 0024 156d C000 f301 caefi xxxX xxxx 
c348 a7dc 0000 £Sa.e 3 004 0000 £9e3 bc39 
ad2f 0700 

If we examine these traces closely we can identify a distinction between them. The DF bit Is set 
with the Sun Solaris ICMP Query reply and not with the HP-UX 110 OS reply. 

If you recall from the # 0F Bit Playground' section Sun Solaris would set the DF bit by default with 
all its ICMP Query replies. HP-UX 10-30, and 11.0x operating systems would initiate, ^efault, a 
proprietary method in order to determine the PMTU using ICMP Echo requests. After the PMTU 
is determined the following ICMP Query replies would have the DF bit set In the IP Header. 

If we are using only one datagram than in most cases we can distinguish between SunSolarfe 
and HP-UX 10.30, and 1 1 .Ox operating systems since the DF bit wfll not be set (and if the PMTU 
is not already determine). 

Afl ICMP Query replies on the same operating system use the same pattern (either echo the 
reserved bit with all replies or not). This enable us to use another ICMP Query message type for 
this fingerprinting method. If we send an ICMP Address Mask request with preserved b.t set. 
the result a Sun Solaris 2.8 machine will produce will be something like the ne*T race. 

13:39:32.262869 if 4 > Y.y-Y-Y > X.x.x.x : i<=<npz address mask request 

{ttl 255, id 13170) 

. 4500 0020 3372 8000 f f 01 el2e YYYY YYYY 
xxxx xxxX .1100 aOfb 4e04 0000 0000 0000 

1B:39:32« 561373 if 4 - <: x.x.x.x* > Y-Y-Y-Y'* icinp: address mask is 

OxffffffOO (DF) (ttl 243, id 51792) 

4500 0020 ca50 cOQO f301 1650 XXXX XXXX 
yyyy yyyy 1200 aOfa 4e04 0000 £f£f ffOO 

We will have both the reserved bit and the DF bit set on the ICMP Address Mask reply, a unique 
pattern Sun Solaris machines have with ICMP Query replies. 

This operating system fingerprinting method enables » to ^^J^^^ 6 " 
Solaris, and HP-UX 10.30 &1 1 .Ox operating systems to the other operating systems. 

79 

Copyright © Oflr Afttn. 20002001 

htipV/www.ny^&ecu fTtv.com 



898-d 60Z/EEI d 6U-1 



20360928*61 



jeegguos | o ' sue; je^ ' eqqou)|-iuoj j ujdgg : go 



W-08-80 



W99:(ss-ium) NOIlttfflO » fl)S609Z6W:QIS3 MULim JhMdJOldSIVllAS «Nl lijfiyfea UJ3)se]l NdfWft W03/OC/9 lVOAOH , 39Vd 

• . o o 

ICMP Ussgefn Scanning 
Version 2*5 

1 have asked Alfredo Andres Omella, author of SING, to incorporate the ability to set me reserved 
bit with his tool. Alfredo has Introduced the -U option along with the ability to identify if this bit is 
set on the reply (if any) we get, with the latest version of SING: 

[root@godfother bin]# ./sing -mask -U lP_Address 
SINGing to IP^Address (IP^Address): 12 data bytes 

12 bytes from IP_Address: icmp_secpO RFl DFl t*=243 TOS=0 "iask-255.255.255.0 
12 tytes from IP_Address: icmp_seq=1 RFl DF! 111=243 TOS=0 mas^255-255^&5.0 
12 bytes from IP__Address: fcmp_seq=2 RFt DF! W-243 TOS*0 mask=255.255.255.0 
12 bytes from IP^Address: icmp_se<p3 RFt DFl tti=243 TOS=0 mask=256,255^55.0 
12 bytes from IP_Address: icmp_seq=4 RFl DF! ttJ=243 TOS^O mask-255.255.255.0 
— IP_Address sing statistics — 

5 packets transmitted. 5 packets received, 0% packet loss 



This method was tested against: Linux Kernel 2.4 test 2 4J5.6; Linux 'f^^^S\ £°* 
3 4- OpenBSD 2.7.2.6; NetBSD 1.4-1/1.4.2; BSDI BSD/OS 4.0,3.1; Solans 2.6,2.7 2 8; HP-UX 
10 20. 11.0: Compaq Ta»64 5.0; AiX 4.1.3.2; Irix 6.5.3, 6.5.8; Ultrix 42. -4.5; OpenVMS y7 1-2; 
Novel Netware 5.1 5P1. 5.0, 3,12; Microsoft Windows 98/98SE, Microsoft Windows NT WRKS 
SP6a, Microsoft Windows NT Server SP4, Microsoft Windows 2000 Family. 



Some operating systems, when receiving an ICMP Query message with the DF bit set, would set 
the DF bit with their replies as well. Sometimes it would be in contrast with their regular behavior, 
which would be not setting the DF Bit tn their replies for a regular query that comes wtth the DP 
bit not set 



6.9-1 DF Bit Echoing with the ICMP Echo request „ 
The tcpdump trace below illustrates en ICMP Echo request sent from a Unux box, using SING p 
to a SUN Solaris 2.7 machine; 

[root®godfather bin]# ./sing -echo -G IP^Addrese 
SINGing to IP Address <IP_Addres*) : 16 data bytes 

16 bytes fronTlP Address: icmp_seg-0 DFl ttl=243 TOS=0 tw**188.289 m S 
It b£es from X»>U""' icmp_seq=l VI ttl-243 *OS=0 tM -JJJ ms 
16 bjtes from XPjtddrete; i«p_ W 2 Jtft tt 1-243 TOS-0 txme-240^*8 ms 
16 bytes from IPlAddress:. iCB©_aeq=3 DF! ttl-243 TOS^O tnne^GO.036 ms 

IP Address sing statistics 

4 packets transmitted, 4 packet© received, 0% packet loss 
round- trip roin/avg/tnax » 188 . 289/224 . 652/260 - 036 mS 
[rootagodfather binl# 



The tcpdump trace 

0 if 

4S00 0024 3372 4000 ffOl 20£0 xxxx 



17:16:23,527050 if 4 » x.X.x.X > y-Y-Y-y* i<^P= «no request (DF) (Wl 
255, id 13170) 



42 The -<S option with SING sets the DF Bit with the ICMP Query requests. 
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yyyy yyyy 080 <> ascd"M04 oooo 37e9 t>c39 
a30a 0800 _ . , 

17 5l6: 23.71SaS0 if 4 < y.y^.y > *** ~ ianp: echo reply (DF) (ttl 
243, id 16227) £3D1 1J>2£ ■ 

scsotx xxxx 0000 adcd D304 0000 37e9 bc39 
a30a 0800 

Most of to operating systems that I have checked this behavior against did the same thing. In 
the reply they produced, the DF bit was set. 

Which operating systems are the test kernels, 

Linux operating systems based on Kernel 2.2.x, and Kernel wren uie v<m 
UHrix v4.2 - 4.5, and Novell Netware. 

Ho^canwedfefrnso/^beftveenf/wseoperatogsysfems? _ 

ICMP Query replies, and Novell Netware uses 128 rt js easy ^ "f""* d U(fr ^ b d 
groups. If we want to further distinguish between LINUX • ^ed^ten* amr 
systems we can send an ICMP Information request or an ICMP Address i Mask ^ U J^° "' B 
• SSoned machines- The machine, which would answerthose.wdl be the one based on the 

Ultrix operating system, 
the DF bit 

Again it is very simple to distinguish between the Microsoft Windows 98 ^^tS^ fei 
tSSSSSL Since the Microsoft Windows 98 family ta using SSjElSX 
their ICMP query replies and Ultrix uses 25S. we can distinguish between those operating 

systems- 

we have here a simple method to distinguish between Microsoft Windows 9 8 / 98 SE, and Ultrix 
• machines to the rest of the operating systems world. 

Another Interesting piece of information is that the Microsoft Windows * 

ICMP Echo request, not echoing with the other types of ICMP query). 

6.9.3 DF Bit Echoing with the ICMP Ttmestamp man With the ICMP 

Since a lot more operating systems answer for an ICMP ^estamp request man wnn 
Address Mask request, we have a bit more difficulty in identifying those. 

Unux machines based on Kernel 2.2*. » 

the Microsoft Windows 2000 Family would not echo back the DF bit with ICMP im 
they produce for ICMP Timestamp request that sets their DF bit. 

Here we can only distinguish belween certain groups of operating systems; again it would be 
according to their IP TTL field value with their replies. 
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Linux would use 255 as its TTL field value for the ICMP Timestamp reply: Ultrix would use the , 
same value- The Microsoft family of operating systems that would answer for this kind of query 
would use 128 as their TTL value. 

Again we have Linux and Ultrfx on the one hand and the Microsoft Family on the other hand. How 
can we further distinguish between those? We can correlate the information {as discussed In the 
next section, or query the "suspicious- machines with another type of ICMP Query message). 

6 9-4 Using all of the Information In order to identity maximum of operating systems 
We can group Linux and Ultrix with the ICMP Echo requests. We can do the same with Microsoft 
Windows 98 / 9S SE & Ultrix using the ICMP Address Mask requests. This would allow us to 
pinpoint the Linux boxes from the first stage. So when we would go into the thrrd stage we would 
know which operating systems are Linux based, which are Microsoft Windows ,98 /98 SE based, 
and which are UHrix based. This would leave us with Microsoft Windows ME and with the 
Microsoft Windows 2000 family machines. 

6.9.5 Why tills would work (for the skeptical) 

All those skeptical would say that if they receive an ICMP Query request with the DF oitset man it 
should be clear that something is wrong and someone is probably trying to scan them. Think 
again. What would happen if a Sun Solaris machine, will query your machine? Than the same 
behavior would be produced. 

This is an ICMP Echo request sent from a Solaris 2.6 box to a Linux box. We can see that the DF 
bit Is set with the request and not set with the reply. But again if some one would mimic this 
behavior with a tool used on a Linux box to query the world, which Is 100% mimicking a Sun 
Solaris request than we would never know if this is a legit request or an attempt for scanning / 
fingerprinting. 

Initializing Network Interface... 
Decoding raw data on interface pppO 

-*> Snort I <*- 
Version 1.6 

By Martin Roescn < roesch@clark.net, www.clark.net/-roesch] 
08/10-23=32:52.201612 y.y.y.y -> 139.92.207.58 
ICMP TTI*:239 TOS:0x0 IDt48€56 DP 
IP: 20 80 SeqiO* ECHO 

39 93 10 A3 00 03 F0 E5 08 09 OA OB 0C 0D 0E OF 9 



10 11 12 13 14 15 16 17 18 19 1A IB 1C ID IB IF 

20 11 22 23 24 25 26 27 28 29 2A 2B 20 2D 2E 2F ■'••«;»*♦•-■' 
30 31 32 33 34 35 36 37 01234567 

08/10-23:32:52,201649 139.92.207.58 -> Y-Y-Y-Y 
ICMP TTL: 255 TOS;0x0 ID:349 
ID:2Q80 Seq:0 ECHO REPXiY 

39 93 10 A3 00 03 P0 E5 08 09 OA 0B 0C 0D OB OF 9 

ao ii 12 13 i4 is i6 17 is 19 ia ib ic id ie if 

20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F ^JJW » * + ' 



30 31 32 33 34 35 36 37 
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Operefog System 



Debian GNU/ UNUX Z2, Kernel 
2.4 test 2 

Redhat LINUX 6-2 Kernel az.14 

Free&SD4.0 
Free BSD 3,4 
OpenBSD 2.7 
OpenBSD 2.6 
NeffiSD 

BSD1 BSD/OS 4.0 
BSPl BSD/OS 3.1 

Solaris 2.5-1 
Solaria 2.6 
Solaris 2.7 
Solaris 2.8 

HP-UX v1 0.20 
HP-UX vl 1.0 

Compaq TruB4 v5.0 

Irisc 6.5.6 

AIX4.1 
AIX3.2 

ULTRIX4.2-4.5 

OpenVMS V7.1-2 

Novell Netware 5.1 SP1 
Novell Netware 5.0 
Novell Netware 3.12 



Windows 95 
Windows 98 
Windows as SE 
Windows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS SP 6a 
Windows NT 4 Server SP4 
Windows. 2000 Professional 
Windows 2000 Server 



Info* Request 



Not Answering 



wot 

Not Answering 
Not Answering 
Not Answering 
Nat Answering 
Not Answering 
Not Answering 
Nat Answering 

Not Answering 
Not Answering 
Nat Answering 
Not Answering 



Not Answering 



Not Answering 
Not Answering 



Not Answering 
Not Answering 
Not Answering 



Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 



Timo Stomp 
Request 

• *- V ! X ■ 



+<-DF) 

*(+DF) f 
♦ (♦OF)' 
+ {+DF) 
+ <-«-OF) 

+ ( + DF) 
+ (+DF) 



+ (+DF) 
*(+0F) 



Not Answering 

+ (+DF) 

+ ( + DF) 
♦ (+DF) 

+ ( + DF) 
+ ( + DF] 

4-(-DF) 

+ ( + DF) 

Not Answering 
Not Answering 
Not Answering 



Not Answering 
+ <-DF) 
+(-DF) 
+ (-DF) 
Not Answering 
Not Answering 
Not Answering 

+ (-on 

H» ( - DF ) 



Address Mask 
Request ; ■ 



Not Answering 

Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 



*( + DF) 
+ ( + DF) 
+.(4DF) 

Not Answering 
+ < + DF) 

Not Answering - 

Not Answering 
Not Answering 

Not Answering 
Not Answering 

+(-DF) 

+ ( + pF) 

Not Answering 
Not Answering 
Not Answering 



+ (-DF) 
Noi Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering, 



Echo Request 



+(-DF) 
+ <-DF) 

+ ( + DF) 
-i-f + DF) 
+ 1 + DF) 
+ ( + DF) 
+ (+DF) 

*( + DF) 



♦ ( + DF) 
+ ( + DF) 
-f ( + DF ) 



+ ( + DF) 
+ ( + DF) 

+ ( + DF) 
*( + DF) 

*(+DF) 
+ ( + DF) 

+ I-DF) 

+ { + DF) 

+C-DF) 
+(^DF) 
+(-DF) 



+ ( + DF) 
+ (+DF) 
+ < + DF> 

+ ( + DF) 
h ( + DF ) 
DF) 

DLL 



ill 



Table 13: DF Bit Echoing 



6,9.6 Combining all together Mr .dtna ICMP Echo requests with the 

SfiZ tSSSnLm. machines.the Linux ;<^"^£g*" 
machines according to the IP TTL field values with the ICMP Echo replies. . 
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DF Bit Echoing with the ICMP Echo request 



Not ECHO 
.the DF Bit 



Unux Kernel 2-*-* 
Other OS's Uuux Kernel 2-4 




TTL Filed 

Novell Netware 



DFBIt Brhoing With the ICMP Address Mask request 

0 

ECHO / \ Not ECHO 

DFBIt / \ the DF Bit 



t . Microsoft Windows 98 / TTL Flted 

Sun Solans Microsoft Windows 98 SE / 
OpenVMS — J 



nF Bit Echoing with the ICMPTImestamp request 
® 

ECHO / \ NQtECHO 

DFBIt / \ the DFBIt 



Linux with Kernel 2*2 Jt 
Linux with Kernel 2.4 
Other OS's Uitrix 

Microsoft Windows 9B/98SE 
Microsoft Windows ME 
Microsoft Windows 2000 Family 



Diagram 9: An example of fingerprinting using the DF Bit Echoing technique 

The second stage would be sending ICMP Address Mask requests with the DF hl ^^* 
samS^eted hostts). Microsoft Windows 96/98 SE and Uitrix based m ^ r ^^^r^J d 
the DF 3 with their ICMP Query reply. We tan car, * 
the Microsoft Windows machines, because of the different IP TTL field values in the igmk 
Address Mask replies. 

We can now also identify the Uitrix machines from the first Step > - we JJJ- Than * 
teavM iK with onlv the Unux boxes. Within two steps we are able of fingerprinting woven 
Sre?5t?MicSoft Endows 98/98 SE and Linux operating systems based on kernel 2Ax 
or on kernel 2.4.x. 
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ICMP Usage In Scanning 
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In the last step of this example we are sending ICMP Timestamp requests with the DF bit set to 
the same group of IPs we are probing. The operating systems which do not echo back the DF bit 
in their ICMP Query replies are Linux operating systems based on Kernel 22.x, or on Kernel 2.4 f 
llltrix, Microsoft Windows 98/98SE. Microsoft Windows ME, and Microsoft Windows 2000 Family, 
Since we already fingerprinted most of the operating systems in this it enable us to fingerprint 
Microsoft Windows ME. and Microsoft Windows 2000 family based machines. 



6.10 Using Code field value? different than zero within ICMP ECHO requests 
An interesting detail I have discovered during the lab experiments I did when I have researched 
ICMP scanning is when a wrong code is sent along with the correct type of ICMP query message, 
different operating systems would send different code values back. 

In the next example t have sent an ICfc/IP Echo Request with the code field value set to 38 instead 
of 0. to a UNUX machine running Redhat LINUX 6.2 Kernel 2.2.14, 

We can look at the tcpdump trace, the type and code fields are in bold type: 

00t21:05. 238649 pppO > x.X.X.x > Y-Y-Y*y: ictnp: echo request (ttl 255, 
id 13170) 

4500 0024 3372 0000 ffQl 0833 xxxx xxxx 
YYYY yyVY 082S afl3 2904 0000 4le4 C339 
17a4 0300 

00i21:0S*485S17 pppO < Y-Y-Y-Y > ae.x-x.x: i<=mp: echo reply (ttl 240. id 
2322) 

4500 0024 0912 0000 fOOl 4233 YYYY YYYY 
xxxx X300C 0026 b713 2904 0000 41e4 c339 
17a4 03 00 

In the ICMP Echo reply LINUX produced the code field value Is set to 38. 

If we examine what RFC 792 requires, we see that LINUX does exactly thaL 

The sending side initializes the identifier {used to identify ECHO requests aimed at different 
destination hosts) and sequence number (If multiple ECHO requests are sent to ^e same 
destination host), adds some data (arbitrary) to the data field and sends the ICMP ECHO 
Request to the destination host, In the ICMP header ihe code equals zero. The recipient should 
only change the type to ECHO Reply and return the datagram to the sender. 

ft a a is 31 



Type | cote=o 






SeqjcnoeNLiTra 





Figure 12: ICMP ECHO Request & Reply message format 
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This also means that we trust another machine to behave correctly, when that host produce the 
ICMP Echo reply. ■ 

LINUX changes the type field value to 0 and sends the reply. The codefield is unchanged, 

I have checked the behavior of my Microsoft Windows 2000 Professional box. I have sent the 
same ICMP ECHO Request message to the Microsoft Windows box (the code field Is In bold 
type): 



.10:03:33.860212 ethO > localhoet . localdotnain > 192.168.1.1: icmp: echo 
request 

4500 0020 3372 0000 feOl 0614 c0a8 0105 

c0*8 0101 0825 £618 6102 £658 0183 c8e2 



10:03 s33. 860689 ethO < 192.168.1.1 > localhOS t . localdomain : lerap = . echo 
reply 

4500 0020 2010 0000 8001 9776 cOaS 0101 
C0a6 0105 0000 de3e 6102 £658 0183 C8e2 
0000 0000 0000 0000 0000 0000 0000 



The Microsoft Windows 2000 Professional operating system Changed the code field value on the 
ICMP Echo Reply to the value of 0. 

This method was tested with various operating systems including LINUX Kernel 2.4t1-8. IBM AIX 
4jc& 3.2, SUN Solaris 2,51 . 2.6 r 2,7 & 2.8. OpenBSD 2,6 & 2.7, NetBSD 1.4.1, 1 A2, BSDI 
BSD/OS 4.0 & 3.1, HP-UX 10.20 & 11.0, Compaq Tru64 v5.0, irix 6.5.3 & 6.5.8, Ultrix 4.2-4.5, 
OpenVMS, FreeBSD 3.4, 4.0 & 4.1 and they produced the same results as the LINUX box 
(Kernel 2.2.x) did. 

Microsoft Windows 4.0 Server SP4, Microsoft Windows NT 4.0 Workstation SP 6a f Microsoft 
Windows NT 4.0 Workstation SP3 f Microsoft Windows 95 / 98 / 98 SE/ ME have produced the 
same behavior as the Microsoft Windows 2000 Professional (Server & Advanced Server). 

We have a fingerprinting method to differentiate between a Microsoft Windows based machine to 
the rest of the operating systems world using code values, which are different than zero, inside 
ICMP Echo Requests. 



6.11 Using Code field values different than zero within ICMP Timestamp Request 

I have decided to map which operating systems would answer to an ICMP Timestamp Request 
that would have its code field not set to zero, and how the ICMP Timestamp reply (if any) will help 
us identify those operating systems. 



6.11-1 The non-answering Operating Systems 

Interesting results were produced* The Microsoft Windows 98/98 SE/ME, and the Microsoft 
Windows 2000 Family that have answered to ICMP Timestamp requests with the code field set to 
zero, now did not produce any reply back* 

This enables us to group together certain versions of the Windows Operating System. 
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The next diagram shows how we can distinguish between the different Microsoft Windows 
operating systems using two datagrams of ICMP Timestamp request. The first one Is a regular 
one; the Microsoft Windows machines that do not answer are Microsoft Windows 95 and 
Microsoft Windows NT 4.0 Workstation with SP 6a. AH other operating systems (that I have 
tested) answer the ICMP Time stamp request. The second stage is sending another datagram, 
this time with the Code field set to a value* which is not equal to zero. The operating systems that 
would, not answer will include Windows 98/98 SE/ME/2000 Family, which are the newer versions 
of Microsoft Windows operating systems. 




ICMP Timestamp Request 



Reply 



No Reply 



Other OS's 



Windows 95 
Windows NT4WRKS 



ICMP Timestamp Request with CODEM) 



Reply 



No Reply 



Other OS's 



Windows 98 
Windows 98 SE 
Windows M£ 
Windows 2000 Proffesional 
Windows 2000 Server 



Diagram 10: Fmger Printing Using ICMP Timestamp Request and Wrong Codes 



It Is quite obvious that Microsoft have tried to change some of their newer operating systems 
fingerprinting in later TCP/IP implementations of their operating systems. For example, the default 
for answering an ICMP Timestamp request was Changed from "no answer" to "answer*, tike UNIX 
and UNIX-lRce operating systems. But the Microsoft programmers / designers / architects / 
security engineers did not think about everything apparently. 



6.11.2 Operating Systems the Zero out the Code field value on Reply 

I was looking to see if there are any operating systems in which answered the crafted ICMP 
Timestamp Query with the Code field set to a value different than zero, which might zero out this 
field value in its ICMP Echo Reply. 

I have found that LINUX operating systems based on Kernel 2.2,x or on the 2.4 Kernel (with the 
various test Kernels) zero out the code field with the ICMP Echo replies they produce. The next 
trace is a tcpdump trace describing ICMP Echo Request and reply from a LINUX 2.4 test Kernel 
6 T to a crafted ICMP Echo Request with a code field different than zero: 
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[rootflgodfafcher /root]# sing -tstamp -x 38 -c 2 IP^Address 
SINGing to IP_Atfdress (IP^Addrese) : 20 data bytes 

20 byte© .f jrom^ir^Addresfi : icmp_seq«0 ttl=243 TOS=0 dif f -24315927 
20 bytes from IP^Address : icmp_seq=l ttl«243 TOS-0 dif f =^24316176 

IP_Address sing statistics — 

2 packets transmitted, 2 packets received, 0% packet lose 
[rodtflgodfatber /root]# 



20:10:18.138486 pppO > x.x.x.x > y*y«y+yi icmp: time Stamp request (fctl 
2SS, id 13170) 

4500 0028 3372 0000 ££01 606C XXXX XXXX 
yyyy yyyy 0d2fi 2e0c 7c04 0000 03af 451a 
0000 0000 0000 0000 

20:10:18 .354222 pppO < y.y.y»y > x<x*x.x: icmp: time stamp reply (ttl 

243, id 15717) 

4500 0028 3dS5 oooo f30i €275 yyyy yyyy 
XXXX XXXX 0e00 888b 7C04 0000. 03a£ 451a 
0422 4e31 0422 4«3l 

20:10:19-134165 pppO > x.x.x.x > y*y.y.y: icmpi time stamp request (ttl 

255, id 13170) 

4500 0028 3372 0000 f£0l <S06c xxxx XXXX 
yyyy yyyy 6d26 2928 7c04 0100 03af 48fe 
0000 0000 0000 0000 

20:10:19.354210 pppO < y..y-y-y > x.x.x.x: icmp: time stamp reply (ttl 

243, id 15718) 

4500 0028 3d66 0000 £301 6278 yyyy yyyy 
xxxx xxxx OeOO 7bed 7c04 0100 03af 48fe 
0422 520e 0422 $20e 




6.11.3 Changed Patterns 

The LINUX operating system behavior with the crated ICMP Timestamp requests Is In contrast 
with its behavior with the crafted ICMP Echo Requests sent with the Code field set to a value 
different than zero. 

This also gives us a unique piece of information that enables us to Identity LINUX machines 
better. 
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Diagram 11: An Example of Finger Printing Using crafted I CMP Echo ATimestamp Request 



The diagram above describes a process in which we can use in order to differentiate between 
certain groups of operating systems. 

The first step Is sending an ICMP Echo request with the code field set to a value different than 
zero. Th© ICMP Echo replies with the code field equal to zero would distinguish the Microsoft 
based operating systems group, from the other UNIX and UNIX-like operating systems. 

Sending ICMP Timestamp requests with the Code field value different than zero to afl participants 
of the group of the UNIX and UNIX-like operating systems will identify LINUX 2.2.x and 2.4 Kernel 
based machines (since they zero out the code field in their replies). 

Sending ICMP Timestamp request to the Microsoft Windows based group of operating systems 
will separate the group to those machines rather being windows 95 or windows NT 4 SP4 and 
above (not answer the query); to those that may be one of the following - Microsoft Windows 98 / 
SE/ME/ Windows 2000 Family (answer the query). 



For a list of ICMP Query message types sent to different types of operating systems with the 
code field set to a value different than zero, and the various ICMP Query replies we got back {if 
any) please see "Appendix D: ICMP Query Message types with Code field 1-0 (tabte)V 



Using the ICMP Error Messages 

6.12 Operating system, which do not generate ICMP Protocol Unreachable Error 

Messages . 
Several operating systems will not generate an ICMP Protocol Unreachable error message, when 
one is expected to be produced, in response to an offending datagram trying to use a protocol, 
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Those operating systems Include: 

• AIX 

• DG-UX 

• HP-UX 



6.13 ICMP Error Message Quenching 

RFC 1812 and RFC 1 122 suggest limiting the rate at which various error messages are sent 
Only few operating systems are known to follow this* 

An attacker can use this to send OOP packets to a random, high UDP port and count the number 
of ICMP Destination unreachable messages received within a given amount of time. 



6.14 ICMP Error Message Quoting Size 

Each ICMP error message includes the Internet Protocol (IP) Header and &t le&st the first 8 data 
bytes of the datagram that triggered the error (the offending datagram) ; more than 8 bytes may 
be sent according to RFC 1 122. 

Most of the operating systems will quote the offending packets IP Header and the first 8 data 
bytes of the datagram that triggered the error. Several operating systems and networking devices 
will parse the RFC guidelines a bit different and will echo more than B bytes. 

Which operating systems will quote more? 

LINUX based on Kernel 2»0.x/2£jc/Z4.t-x f Sun Solaris, HPUX 11.x, MacOS 7.55/8. x/9.04. Nokia 
boxes, Foundry Switches (and other OSs and several Networking Devices) are a good example. 

The fact Is not new. Fyodor outlined this In his article "Remote OS Identification by TCP/IP 
Fingerprinting"* 3 . 

The idea is in trying to differentiate between the different operating systems that quote more than 
the usual. How can this be done? Looking for example on the amount of Information quoted. Is 
there a limit to the quoted size? Will the quoted data be the entire offending packet or just part of 
it? Will the quoted data be the echoed correctly? Will extra bytes will be padded to the echoed 
data? and some other parameters. 

The next example Is with Sun Solaris 7. 1 have sent a UDP datagram to a closed UDP port 

00:13:35.559347 pppQ > x.x.x.x.lOB4 > Y- Y*y .y. 2000 z Udp 0 (ttl 64, id 
44551) 

4500 001c ae07 0000 4011 7aa4 XXXX xxxx 
YYYY YYYY 043 c 07d0 0008 alac 

00:13:35*923631 pppO <: y.y.y-Y > X-X*X*X: icmp: Y-Y~y*Y udp port 2000 
unreachable Offending pkt: x.x.x.x.1084 > y,y. y.y.2000 : Udp 0 (ttl 45, 
id 44551) (DF) (ttl 236, id 63417) 

4500 0030 f7b9 4000 ecOl 44e5 yyyy yyyy 

xxxx xxxx 0303 4f3C 0000 0000 4S00 001C 

ae07 oooo 2dii sda4 xxxx xxxx yyyy yyyy 
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043c 07d0 0008 alac 

Please note that for having more than 8 data bytes quoted, you need to have data in the 
offending datagram. If not. ttiere is nothing to quote beyond the regular 8 bytes (usually, If the OS 
i$ not padding other data bytes). 

The next example is with Sun Solaris 8. 1 have sent a UDP datagram to a closed UDP port, 
adding BO bytes of data to the datagram. 

[rootegodtather) # hping2 -2 -d so -c l y.y.y.y 

cthQ default routing interface selected (according to /proc) 

KPING y.y.y.y (ethO y.y.y.y) : udp mode set, 28 headers -t- 80 data bytes 

ICMP Port Unreachable from y.y.y.y (y.y-y.y) 

y.y,y,y aping statistic — - 

1 packets txamitted, 0 packets received, 100% packet loss 
round- trip rain/avg/max «• 0.0/0.0/0,0 ms 

The tcpdump trace: 

11:52:50.830363 ethO > x.x.x-x.2198 > y.y.y.y-0: udp 80 {ttl G4, id 
1724 0) 

4500 006C 4358 0000 4011 99ae xxxx XXXX 

yyyy yyyy osse oooo 0058 8b5£ sess 5858 

5858 5858 5858 5858 5858 5858 5858 5858 

5858 5858 5858 5858 5858 5858 5858 5858 

5858 5858 5858 5858 5858 5858 5858 5858 

5858 5858 5858 5858 5858 5858 5858 5858 

5858 5858 5858 5858 5858 5858 

ll:52;5i-.3G7331 etnO < y.y.y.y > x.x.x.xj i craps y.y.y.y udp port 0 
unreachable Offending pkt; x~x.x-x.2138 > y.y.y.y. 0: udp 80 (ttl 48, id 
17240) (DF) (ttl 231, id 49576) 

4500 0070 cla8 4000 ©701 3469 yyyy yyyy 
xxxx xxxx 0303 bf05 0000 0000 4500 006C 

4358 oooo 3011 a9ae xxxx xxxx yyyy yyyy 

0896 0000 0058 8b5f S85B 585B 5858 5858 

5858 5858 5858 5858 5858 5858 5858 5858 

5858 5858 5858 5858 5858 5858 5858 5858 

5858 5858 5858 5858 5858 5858 5858 5858 

The result is an ICMP Port Unreachable Error message that will echo only 64 bytes of the 
offending datagram's data portion. 

The Hmlt of 64 bytes quoted from the offending packet's data portion is not limited to Sun Solaris 
only. HPUX 1 1 .x, MacOS 7.S5/8.X/9.04, will do the same. 

Other operating systems / networking devices will have their own barriers. For example, LINUX 
based on Kernel 22.Xl2A.x~t will send and ICMP Error Message up to 576 bytes long. UNUX will 
quote 528 bytes from the data portion of the offending packet (576 minus 20 bytes of usuail IP 
Header, minus 8 bytes of the ICMP Header, minus the offending packet's IP Header that is 20 
bytes will leave you with 528 bytes of data portion. This is no IP options are presented). 

I know an operating system, and a family of networking devices that will pad extra data to the 
echoed offending packet LINUX case is detailed in the next section. The next example is with 
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Foundry Networks Serveriron running software version 07.1 .02T12. 1 have sent a UDP datagram 
to a dosed UDP port on the Foundry switch: 

[rootogoaf actier] # hping2 -2 -c x y^y-y-y 

ethO default routing interface selected {according to /proc) 

HPING y-y-y.y (ethO y-y-y.y) * udp mode set, 2s headers + 0 data bytes 

ICMP Port Unreachable from y-y-y.y (y-y.y-y) 

— - y-y-y-y bping statistic 

1 packets tramittecl, 0 packets received, 100% packet loss 
round- trip min/avg/max = 0.0/0-0/0*0 ins 
[rootftgodf atherl # 



12 : 0B 1 47 -793503 ethO * X.X-X.X.2498 > y.y.y-y.0: udp 0 (ttl 64 , id 
44437) 

4500 001c ad95 0000 4011 885f aoOut xxxx 

yyyy yyyy 09c2 oooo ooofc fc»i3f 

12s 08> 43. 240206 etho < y.y.y.y > x.x.x.x: icrap: y.y.y.y Udp port 0 
unreachable Offending pkt: x.x.x.x.2498 > y*y t y.y-0: udp 0 (ttl Si, id 
44437) (ttl SI, id 17453) 

4500 0044 442d 0000 3301 feaf yyyy yyyy 
xxxx xxxx 0303 739c 0000 0000 4500 001c 
a<i9S 0000 3311 955f xxx»c xxxx yyyy yyyy 
09C2 0000 0008 bl3f dd^C 2*16 38el 7646 
7aaa 9d41 

As it seems Foundry switches will pad 12 bytes with ICMP Port unreachable. 

Other fingcrptinting facts that are outlined through this section will halp us to differentiate between 
the operating systems, which carry the same behavior. 

I have examined three ICMP Error Messages a Host can issue: 

• ICMP Port Unreachable 

• ICMP Protocol Unreachable 

• ICMP IP Reassembly Time Exceeded 

Other ICMP Error Messages, which a Host can issue and should be checked to see if they hold 
more fingerprinting differences, are: 

• Source Quench 

" • Parameter Problem 



6-15 LINUX ICMP Error Message Quoting Size Differences / Trie 20 Bytes from No 
Where 

We must understand that there are differences between the different ICMP Error messages, not 
only with their meaning, but also with their implementation. I was expecting that several 
characters with the ICMP Error messages will be the same along all of the ICMP Error Messages, 
but I was wrong regarding few operating systems. 
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The most interesting case fe with the LINUX operating system based on Kernel Z2.X and 2.4.t-x. 

The next example Is with LINUX based on Kernel 2-2.1 6 as the targeted machine, eliciting an 
ICMP Port Unreachable error message: 

00:21:30.199408 pppO > x.x,x.x.2066 > y. y.y.y.2000 z udp 0 (ttl 64, id 
1732) 

4500 001C 06c4 0000 4011 C$95 xxxx xxxx 

yyyy yyyy o$i2 o7do oooa 4484 

00:21:30-493691 pppo < y-y.y-y > x.x.x.x: icmp: y-y-y-y udp port 2000 
unreachable Offending pkt^ x,:>c.x.x. 2066 > y .y .y .y. 2000 : udp 0 (ttl 44 # 
id 1732) [tos QxCO] (ttl 238, id 53804) 

45c0 0O3A d22c 0000 eeOl 4e60 yyyy yyyy 
xxxx xxxx 0303 a88e 0000 0000 4500 001c 
gec4 oooo 2cii dc95 xxxx xxxx yyyy yyyy 

0812 07dO 0008. 4484 



The quoted data is the entire offending datagram. LINUX ICMP Error messages will be up to 576 
bytes bug according to the LINUX source code. 

The next example is with LINUX as the targeted operating system. With this example I have sent 
a protocol scan with NMAP; 

13:14:56.942897 < x.X,x.x > y.y.y.yi ip-proto-38 0 (ttl 39# id 37623) 
4500 0014 92f7 0000 2726 02cb xxxx XXXX 

yyyy yyyy 

13 t 14: 56. 942964 > y*y-y-y > x.x.X.X: icmp: y.y.y.y protocol 3.8 
unreachable Offending pkt: x.x.x.x > y.y.y.y: ip-proto-38 0 (ttl 39, id 
37623) [to© OxcO] (ttl 255, id 1884) 

45c0 0044 075c 0000 ffoi b59a yyyy yyyy 

XXXX xxxx 0302 fbia 0000 0000 4500 0014 

92f7 oooo 2726 02cb xxxx xxxx yyyy yyyy 

0050 dc84 ae6£ 6910 0000 0000 5004 0000 
bd89 0000 

LI NUX adds to the entire offending packet that was quoted, another 20 bytes. 

Since LINUX handles the ICMP Protocol Unreachable Error Messages like the ICMP Fragment 
Reassembly Time Exceeded Error Messages we win see the same pattern with ICMP Fragment 
Reassembly Time Exceeded: 

[rootegodfather bin]* hping2 -c 1 -x -y y-y.y.y 
pppO default routing interface selected (according to /proc) 
HPIKG y.y.y.y pppO y-y-y-y) : flags are set, 40 headers + o data 
bytes 

y-y.y.y hping statistic 

1 packets tramitted; 0 packets received, 100% packet loss 
round-trip min/avg/raax = 0*0/0.0/0.0 m<5 
[root@godf ather bin] # 

The tepdump trace: 
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19:49:22.999108 pppO > x.x.x.x.cvspserver > y.y.y-Y-O: , 
1709055398:1709055398(0) win 512 (frag 35247: 2 0©0+) <DP) (ttlS4) 
4500 0026 S9a£ 6000 4006 eOf f xxxx xxxX 

yyyy yyyy o^si oooo ssde idae 6a.oi 476b 

5000 0200 bf71 0000 

19-49 ;53 .303196 pppO < y.y.y*y > x.x.x.x: icmp; ip reassembly time 
exceeded Offending pkt: x.x.x.x.cvspserver > y*y.y.y.0: - 
1709055398:1709055398(0) win 512 (frag 35247 ;2Q©0+) (DP) (ttl 45) [toe 
OxcO] (ttl 238, id 379) 

45co 0058 017b 0000 eeOl la.49 yyyy yyyy 
xxxx xxxx ObOl 3caf 0000 0000 4500 0028 

89af 6000 2d06 f3ff xxxx xxxx yyyy yyyy 

0961 0000 GSde lda6 6a01 476b 5000 0200 
bf71 0000 fiOld lfOd 7a04 5045 0100 0000 
4146 4345 4a45 4£46 

Since LINUX'S ICMP Error messages will not be bigger than 576 bytes long, if the offending 
packet will be big enough (not likely in real world situation) we will not see the added 20 bytes in 
the ICMP Fragment Reassembly / ICMP Protocol Unreachable error messages. 

This unique pattern will allow us to identify LINUX based machines even if the Precedence Bits 
value with the LINUX ICMP Error messages will be changed to 0x000. 




6.16 Foundry Networks Networking Devices Padded Bytes with ICMP Port 
Unreachable(s) / The 12 Bytes from No Where 

Linux is not the only operating system that will have weird data bytes padded to one of his ICMP 
Error messages. 

Foundry Network's networking devices will pad extra 12 bytes of data wtth their ICMP Port 
Unreachable Error messages. Our first example is with a Serverlron switch running software 
version 7.1.02T12, eliciting an ICMP Port Unreachable error message: 

[rootogodf ather] # hping2 -2 -c 1 y.y*y*y 

ethO default routing interface selected (according to /proc) 

EPING y*y*y-y (ethO y.y-y-y) : udp mode set, 2Q headers + o data bytes 

ICMP Port Unreachable from y.y.y.y (y.y*y*y) 

Y-Y-Y-Y bping statistic - - - 
1 packets tramitted, 0 packets received, 100% packet loss 
round- trip min/avg/max s O.O/0-O/O.O me 
[rootegodf ather] # 

12:08:47.793503 ethO > x.x.x*x.249S > y.y«y«y.0: udp O (ttl $4, id 
44437) 

4500 001C ad95 0000 4011 8$5f xxxx xxxx 
yyyy yyyy 09c2 oooO ooos bi3f 

i2r0S;48-240208 etno < y.y.y.y > x.x.x.x: icmp: y-y-y-y udp port o 
unreachable Offending pkt: x.x.x.x.2498 > y.y.y.y. 0: udp 0 (ttl 51, id 
44437) (ttl 51, id 17453) 

4500 0044 442d 0000 3301 feaf yyyy YYYY 
XXXX xxxx 0303 739c 0000 0000 4500 001c 
94 
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ad95 0000 33H 955£ xxxx xxxx. yyyy yyyy . 
05c2 0000 0008 bl3£ dd2c 2al6 38el 76*6 
7aaa 9d41 

From the tcpdump trace we can see that the offending packet's IP header and the first 8 data 
bytes were echoed correctly. Right after those, 12 bytes were padded, that came from nowhere. 



The next example is with Foundry Network's Biglron 8000 running software version 6.6.05T51. 
With this test i have sent a UDP datagram with 80 bytes of data to a closed UDP port on the 
Biglron 8000: 

[root@godf ather /root] # hping2 -2 -C 3 -d 80 y*y.y.y 
pppO default xouting interface; selected (according to /proc) 
HPIKG y.y.y-y (pppo y-y*y*y ) : udp mode set, -28 headers + 80 data 
bytes 

icmp Port unreachable from y.y.y.y (y-y-y-y) 
ICMP Part Unreachable from y,y.y-Y (y-y*y*y)- 
ICMP Port Unreachable from y.y.y-y (y-y.y.y) 

y.y.y-y hping statistic 

3 packets tramitted, 0 packets received, 100% packet loss 
round- trip min/avg/max = 0.0/0.0/0.0 ins 
IrootQgodf ather /root] # 

11:40:35.694235 pppO > x.*. ?e.x. 2779 > y.y.y.y-O: udp 80 (ttl 64, id 
25211) 

4500 DOSc 627b 0000 4011 2e7a xspn x xao c 
yyyy yyyy Oadb 0000 0058 3d09 5858 5858 
5350 5858 5858 5658 5S58 5858 5858 5658 
5858 5858 5858 5858 5858 S858 5858 5858 
5858 5858 5858 5858 5858 5858 5858 5B58 
5858 5858 5858 5858 5B58 5858 5858 5858 
5B5S 5858 5858 5858 5858 5858 

11:40:37.913018 pppO < y-y-y.y > x.x.x.x: letup: y.y-y.y ndp port 0 
unreachable Offending pktt x.x.x.x.2779 * y.y.y.y-0; udp 80 (ttl 52, id 
25211) (ttl $2, id 60504) 

4500 O044 ec58 0000" 3401 bbd4 yyyy yyyy 

xxxx. xxxx 0303 edf3 0000 0000 4500 006c 
;627b 0000 3411 3a7a aooot xxxx yyyy yyyy 

Oadb 0000 0058 3d09 Icld lelf 2021 2223 

2425 2627 

Again, the offending packet* s IP Header and the first 8 data bytes are quoted correctly. 12 data 
bytes are padded right after, 

A nice pattern that allows us to identify . Foundry Network's networking devices. 



6,17 ICMP Error Message Echoing Integrity (Tested with ICMP Port Unreachable) 

When sending back an ICMP error message, some stack Implementations may alter the original 
IP header, which is echoed back with the ICMP error message. 
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If an attacker examines the types of alternation that have been made to the headers, he may be 
able to make certain assumptions about the target operating system. 

The only two field values we expect to be changed are the IP time-to-live field value and the IP 
header checksum. The TTL field value changes because the field is decremented by one, each 
time Hie IP Header Is processed. The IP header checksum is recalculated each time the IP TTL 
field value decremented. 



Fyodor gives the following examples In his article "Remote OS detection via TCP/IP Stack Finger 
Printing" 44 : 

'For example, AIX and BSD I send back an IP total length 1 field that is 20 bytes too high. 
Some BSDi; FreeBSD, OpenBSD. ULTRIX, and VAXen change the IP ID that you sent 
them. While the checksum is going to change due to the changed TTL anyway, there are 
some machines (AIX r FreeBSD, etc.) which send back an inconsistent or 0 checksum. 
Same thing goes with the UDP checksum," 



This section deals with the ICMP Port Unreachable error message. 



ADC 4.2.1 , 4.3, 4.3 fix pack 2 

In the next example I have sent a UDP datagram to a closed UDP port on an AIX 4.3 machine 
using HPING2. This is the tcpdump trace: 

12=33:17-319275 pppO > X.X.X.X.21S0 > Y-y-Y-V-O: udp 0 [tos 0x10] (ttl 
G4, id 47349} 

4510 001c b6f5 0000 4011 3b«a xxxx xxxx 

yyyy yyyy 0870 oooo ooos disc 

12:33:17.614823 pppO < y.y.y.y > x.x.x.x: icntp: y*y.y-y ud P P ort 0 
unreachable offending pkts x.x.x.x.sigo > y.y.y.y. 0: udp o Itos oxiol 
(CCl 49. id 47343, bad cfcsum aaeai) [tos 0x10] (ttl 241, id 17965) 
4510 0038 4€2d oooo fioi 5da6 yyyy yyyy 

xxxx xxxx 0303 f470 0000 0000 4SlO 0030 
bSfS OOOO 3111 aaoa xxxx xxxx yyyy yyyy 
0870 oooo oooa oooo 

We can Identify several changed between the original IP Headers to the echoed ICMP Header 
with the ICMP port unreachable error message. 



• IP Total Length Field - The total length field with the original UDP datagram equal to 
28 bytes. With the echoed original IP header this value was changed to 48 bytes. 20 
bytes more than the original UDP datagram's length. 

• IP TTL Field value - With the ICMP error message this value is set to the value, 
which reached its final destination (with this example the targeted host). When it 
reached it target the TTL was set to 49. We also learn the target Is 64-49 =15 hops 
away, 

• IP Header Checksum - The IP Header checksum was changed because the IP Total 
Length filed value and the IP TTL field value were changed. 
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ICMP Usage In Scanning 
Veretan 2.5 



• UDP Header Checksum -The UDP header checksum with the echoed information 
equal to zero. 



AIX 4.1 

In the next example I have sent a UDP datagram to a closed UDP port on an AIX 4.1 machine 
using HPING2. This is the tcpdump trace: 

00:56: 07. 894$12 pppO > x.x.x.X.1594 > y.y.y.y.O: udp 0 [tos 0x8] (ttl 
€4, id 2153) 

4S0B OOld 0869 0000 4011 c54f xxXX xxxx 

yyyy yyyy 063a oooo oooo 4c93 
00 = 56:08.204551 p P3 ?o < y.y.y.*y > x.x.x.x: icitip: y.y.y*y udp port 0 

-unreachable Offending pkt: x.x.X.X-1594 > y:y.y.y^0: udp 0 [tos 0x83 
(ttl 47, id 2153, bad cksurn d54f l) [tos 0x8] (ttl 239. id 1065) 

4Sofl 0038 0429 oooo efoi iaB3 yyyy yyyy 

XXXX XXXX 0303 aal3 0000 0000 4508 0030 
0869 OOOO 2fll d64f xxxx xxxx yyyy yyyy 
063a 0000 0008 4C93 

We can Identify several changed between the original IP headers to the echoed ICMP Header 
With the ICMP port unreachable error message. 

• IP Total Length Field - The total length field with the original UDP datagram equal to 
28 bytes- With the echoed original IP header this value was changed to 46 bytes. 20 
bytes more than the original UDP datagram's length. 

* IP TTL Field value - With the ICMP error message this value Is set to the value, 
which reached its final destination (with this example the targeted host). When rt 
reached it target the TTL was set to 47. We also leam the target is 64-47 = 17 hops 

. ^Header Checksum - The IP Header checksum was changed because the IP Total 
Length filed value and the iP TTL field value were changed. 

ICMP Error Message Echoing Integrity with different 4jc v f^^^^^ iirn Th . 
In contrast to AIX version 4.3 and 4.2.1 AIX version 4.1 use the onginal UDP Checksum. This 
detail helps us to differentiate between the different versions of AIX. 



Stte wt example 1 have sent, again, a UDP datagram to a close UDP port this time on a BSD1 
4.1 machine. The following is the tcpdump trace: 

01:01:11.128420 pppO > x.X.x.x.2933 > y.y-y^y-O: udp 0 [tos 0x8] (ttl 
64, id 49317) 

4508 001c C0a5 0000 4011 9209 xxxx xxxx 

yyyy yyyy ob75 oooo ooos cc4e 

01:01:11-404552 p PP 0 < y.y.y.y.4 > x.x.x.x: icn** ^ y ;LVtbos°0x8] 
unreachable Offending pkt: x.x.x.x.2933 > y.y.y.Y.O- udp 0 [tos 0x81 
(ttl 53 , id 49317, bad exsum 01) (ttl 242, id 16127) 

4500 0038 3eff 0000 f20l 61ab yyyy yyyy 
97 
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xxxx 0303 C22S 0000 0000 4508 0030 
COaS 0000 3511 0000 *x*x xxxx yyyy yyyy 

ob?s oooo oooe cc4e 



Again several changed were made to the original IP Header . 

IP Header Checksum -ctanged now it equal to zero! 



FreeBSD 3jc up to 4.1.1 (not including) 

The next example is with FreeBSD 4.1 ■; 

00i52il9. 0S57SS pppO > x.x.x.x. 1393 > y v vv O. „d n n n- « - n , 

64, id 58965) y.y.y.y.oi udp o [tos Oxfi] (etl 

4508 001c «6b5 0000 4011 3f63 xxxx xxxx 

yyyy yyyy os7i oooo oooo «ssc 

00;52 =19.464545 pppO <Vvv-u-->-„„„ 

unreachable Offending pkt- x'x * * "^o^ ^^-y ud *> 0 

(tti 47, id 2 i 590 , ^cU-s^n'^i^rt/^sa^ ° ttOE 03581 

4SO0 0038 6bf7 0000 eeOl Obbd yyyy yyyy 

xxxx XXXX 0303 87f3 0000 0000 4S0S 001c 

SSe« 0000 50S3 xm yyyy yyyy 

0571 0000 0006 0000 ' ™^ 



toeoripnal datagram this field value was e655, with the echoed IP header is 

The IP HL f,e, ^ , t° ha$ Cha " 9ed - The ^et is 64 - 47 = 17 hops away. 
TheJP Header Checksum have changed because of the parameter ^changed 

The UDP checksum is changed and now It equal to zero! 



Operating 
Systern , 

LINUX Kernel 


| PF Bit set 
wfth^hB 
Reply? 


IP Total : 
Length 


..'IP-' 
Identificatlo 
n 


IP TTL; 
field value 


. IP Header . ^ 
Checksum 


\ UDP 

Checksum, 

• » •* . 


LINUX Kernel 
2.4 


No 
No 


Sams 
Same 


Same 
Same 


Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count 


Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 


Same 
Same 



mrtf^MptrntMatfyi*^ $gT?Bg1g240 ; Patches 
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Changed 
j because of new 
parameters. 


Changed. 

NowequaMo 

ZERO! 


Changed 
because Of new 
parameters. 


Changed. 
Now equal to 
7EKOI 


v^nangeo. how 
equals to ZERO! 


Same 


Changed 
because of new 
parameters. 


Same 


Changed 
. because of new 
parameters. 


Same 


Changed 
because of new 
parameters 


Same 


Changed 
because of new 
parameters. 


Same 


Changed 
because of new 
parameters. 


Changed. 
Now equal tq 
ZERO! 


Changed 
because of new 
parameters. 


Changed. 
Now equal to 
ZEROJ 


Changed 
because of new 
parameters. 


Changed. 
Now equal to 
ZERO! 


Changed 
because of new 
parameters. 


Same 



FreeBSD4.0 



FreeBSD4>11 



BSDI4.1 



Sun Solaris 
Z6 



Sun Solaris 
2.7 



Sun Scran's 
Z3 46 



HPUX11.0 



Compaq 
Tru64 



DG-UX5.6 



ADC4.3fp2, 
3,4.2.1 



AIX4.1 



No 



Same 



No 



No 



Yes 



Yes 



Yes 



Same 



Changed 
(20 bytes 
mom) 



Same 



Same 



No -> Yes 



No 



No 



No 



No 



Same 



Seme 



Changed 
(20 bytes 
more) 

Changed 
(20 bytes 
more) 



Changed. 
The first 
two bits 
are Hipped 
with the 
second 
pair. Gives 
a new 
value. 
Same 



Same 



Same 



Same 



Same 



Same 



Same 



Same 



Same 



Same 



to hop 
count 



Changed 
accordi 
to hop 
count 
Changed 
according 
to hop 
count 

Changed 

according 

to hop 

count 

Changed 

accoiding 

to hop 

count 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count. 



Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count 



46 The DF Bit Is set 
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. Operating 
-System 



UIXR1X 



OpenVMS 



Microsoft 
windows 98 

Mirosoft 

Windows 

9BSE 

Microsoft 
Windows ME 



Microsoft 
Windows NT 



Microsoft 
Windows 
2000 Family 



•DF Bit' set 
with the 
Etepfv? 



No 



No 



No 



No 



No 



No 



IPTotal 1 IP I ip-mt 
length. | Identlficatio J . field value' 
* fi 



Same 



| Changed. 

I The first 
two bits 
am flipped 

| with the 

I second 
pair. Gives 

I anew 

I value. 

Changed, 
The first 
two bite 
are flipped 
I with the 
second 
pair. Gives 
anew 
value. 



Changed 
according 
to hop 
count 



Changed 
according 
to hop 
count 



Same 



Same 



Same 



Same 



Same 



Same 



Same 



I Same 



Changed 

according 

to hop 

count 

Changed 

according 

to hop 

COUnL 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 



IP.Header 
: Checksum 



Changed. Now 
equals to 2HROI 



Changed. Now 
equals to ZERO! 



Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 



UDP . 
• Checksum 



Changed. 
Now equal to 
ZERO! 



Changed. 
Now equal to 
ZERO! 



Same 



Same 



Same 



Table 14: ICMP Error Message Echoing Integrity 

|18No™.l Nehrare Echoing htegnty Bus with ICMP Fraame „ t R^embly Time 
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I CMP Usage in Scanning 
Version 2.5 ■ 

We expect this value to decrement from the value initially assigned but not to be zero Sir™* 
With the Novell Netware error message we can see that the Checksum echoed is miscalculated. 

The next example is with Novell Netware 5.1: 

[rootsgodfattoer hping2 -c 1 - x _ y y y v v 

TOPO defame routing interface selected (according to /proc) 

Y-y.y-y hping statistic -~ 

round-trip rnxn/av^/max = O.O/O.o/O.O tns 
Irootogodfather bin] # 

The Trace: 

20,15:28.008893 p P? 0 > X . X ,x.x.l86S > Y-y.y.V 0- 

«7160M9,M7160M 9 (0) win 512 (f^ Bteii^, * ( W («1 M ) 

4500 0028 e4da 6000 4006 c236 xxxx xx*x 

yyyy yyyy 0745 0000 28f5 3eei esse 9fis 

5000 0200 GSdL2 0000 
20:12:41.313202 pppO < y.y-y v ^ X x y y. -i ™^ _ 

4500 0038 2577 0000 SfOl b28f yyyy yyyy 
xxxx xxxx 0b01 ©55f 0000 0000 4500 002S 
e4da €000 0006 6336 xxxx xxxx yyyy yyyy 
0749 0000 28f5 3e61 



S , ^r reMd ! nCe b J?. WiUl ,CWP EnOT Messages (Identifying LINUX) 



□ 



Precedence 



TOS 



MR2 



Figure 13: The Type of Service Byte 
The TOS Byte- consists of three fields. 
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KSffl' WWch fe "* » n 3> is *> ^ IP Datagram. It has eight 



Precedence 


Definition 


i ■ o 


Routine (Normal) 


1 


Priority 


2 


Immediate 


3 


Hash 


4 


Rash Override 


5 


Critical 


6 


Interne twort; Control 


r 


Metwork control 



Table 15: Precedence FteW Values 
Higher priority traffic should be sent before lower priority traffic. 

12Z!£%2J5?• 4 f U Z!Z*£ ** ^yP^f-ServIce" field, it is Intended to describe how the 
otSg^m " ^ b6hveen delay, reHability, and cost in ™5ng Zp 

RFC 1122 Requirements for Internet Hosts - Communication Layers, states: 

"?3SosSS2 fe aVanaWe ^ RFC 1812 R ^ irements ** * Version 4 Routers: 

ET^StoZ fi SK2P g, *J f 2?* 8t a "' MUST have meir ,P Precedence field set to 
£mp£?..~L£ f ,P preccden « fleW in the packet that provoked the sendlnq of the 
c U6 "5 "J* 85 ^- A" °*er ICMP error messages {DotOnUa^SSiS^ 

1 ^ Ch6cked ' neaff y a » 0f ^ m ■» value of 0x00 for the 

All butUNUX 



RFC 791 - Internet Protocol, Etfe^^, 
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Jh2'Sli?£2 , "^" d .i l his .e»? "R'mole OS Jdsnliffcaton by TCP/IP Fingemrinting- « 

In the next example we have sent one UDP packet destined to oort 50 fwhfeh k h^ph nn 
delation machine) torn one LINUX machine to another^ ! boK5°iSS SSS 6 if 

troot®stan /root]# hping2 ~2 192.158.5.5 -p So -c 1 
default routing not present 

52 195 - 1€a - 5 - 5 (eth0 udp mode set, ,» headers + o data 
XCMP Port Unreachable, from 192.1*8.5.5 (kenny.sys -security, com) 
192.168.5,5 hping statistic 

1 packets tramitted, 0 packets received, 100% packet loss 
round : trip nd*/av<j/max - 0.0/0. 0/0. o ms P 

Kernel filter, protocol ALL, raw packet socket 
Decoding Ethernet on interface ethO 

UDP TTL: 64 TOS=0x0 ID:572 5 4 St*U 
I>en: 8 

™ 2 " 12 = S4s47 * 2743e0 "2.158.5.5 192.168.5.1 
XCMP TTL:255 TOS:0xC0 ID:0 

DESTINATION UNREACHABLE: PORT UNREACHABLE 

00 00 00 00 45 00 00 1C DP A€ 00 00 40 11 OF D4 E & 

CO A8 05 01 CO A8 05 05 0 9 74 00 32 00 0$ 6A Bl ! 1 .\" i .2 .' j ] 

23^^ not only l^d to ICMP Qe^nation Unreachable Port 

Lets examine the next trace: 



00:30:08.339490 < x * x.x > y.y.y.y- ip-proto-72 0 (ttl 49, id 38624) 
4500 0014 96e0 0000 3148 f4b£ xxxx xxxx 
yyyy yyyy 

00:30:08.339559 > y.y.y.y > x,x.x.x: icmt>: y.y y.y orotocol 72 

45c0 0044 0025 0000 ff 01 bcdl yyyy yyyy 
xxxx xxxx 0302 fbla 0000 0000 4S00 0014 
96e0 0000 3148 f4b£ XXXX xxxx yyyy yyyy 
0050 d&09 621b 96f7 0000 0000 5004 0000 
df71 0000 

^ ,C MP error message produced by a LINUX machine based on Kernel 22. 14 is Destination 
was useci is again OxcO. Which rs an unused Precedence bits value. 
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Just to remind the reader - LINUX is not a router. 
6.20 TOS Bits (=ffeld) Echoing with ICMP Error 

ssiSasr * * e TOs fiew w,th .*■ offendin9 paeket 116 set to a »^ difre ^ *« ^ 

JESE"" SeVera ' ° PeratIn9 SyStemS WI " «»" thB T °S fi^ld back with the iCMP error 
Sue 3 ^ ^ A ' X 4 ' 3 maChbe> Wh6re 3 UDP data ^ m h with a TOS fie,d 

4510 001c b8£5 0000 4011 9bea mx xxxx 
yyyy yyyy 0870 0000 0008 d!8c 

4S10 0038 462d 0000 flOX 5da$ yyyy yyyy 
xxxx xjooc 0303 £470 0000 0000 4510 0030 
bafS 0000 3111 aaea XXXX Xxxx yyyy yyyy 
0870 0000 OOOB 0000 

Si^Jf Se0n ?? m ^ 018 TOS field va,ue was echoed back byth* AJX machine Thi* 
was tested against AfX 4.1, 4.Z1, 4,3. 4.3 fix pac*2. y ^ WA machine. This 

The next example is with DGUX 5.6: 

S; s Ji a 2rfSf L7 Ppp ° ? x -*- x **: 1074 * r-y-y-y-n- «*"o cto* M (tta 

001c b8d2 0000 4011 a037 raxx xxxx 

yyyy yyyy 0432 ooo*> oooe d9ei 

«... <«! = 2 ? srss? & saisri: iraK 1 * °* 0 
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4508 0038 4258 0Q00 3401 22a6 yyyy yyyy 
dSOB c41e 0303 fBb7 0000 0000 4S08 001c 
b8d2 0000 3411 ac37 xxxx xxsoc yyyy yyyy 
0432 000b 0008 0000 



fl° W 2f n ^differentiate between DGUX and AIX? If we will pay attention to the echoina 

So i^wT ,P J 0,a, ' CT9th fieW Va,ue ' the id offend^ Heade? to a 
value 20 bytes higher than the original. DGUX quote this field vaJue correctly 

melsSe^^ ' navefound echoing the TOS field value with ite ICMP error 

hlS'tesS): 0Peratln9 SySt&mS ***** on KM 2 2 * & 2" 4 <* e v *™"* of the Kernel 

« :5 i°d 4 i 5 ^f os ppp ° - > y.y.y-y^ udp o tt= 8 0.103 ctti 



4510 001c 3e50 0000 41011 eSb2 3DCXX xxxx 
yyyy yyyy 07a0 0000 0008 a27f 



00:50:44.154556 pppO < y V .V v > * x v ^. . 

unreachable Offering pkt x I x * ^« 1 t^' r^'^* 1 . 1 *»P 0 
47 ' 15952) [tos OxdO]. (tti 238, id S4G62) 

45d0 0038 d586 0000 eeoi aoaf yyyy yyyy 
Jocxx xxxx 0303 52d5 0000 0000 4510 001c 
3e50 .O00O 2fll £7b2 xxxx yyyy yyyy " 

07a0 0000 0008 a27f 

m^t 6 ^^ ? l J em Wi ! h U I*UX fe $effin 9 Precedence field value to OxcO with ICMP error 
TolleKut ' PS US t0 dffferenliate UNUX **» ** o*er operating systems ta! echo ST 

hI NU ^ RFC 1812 instructions for routers regarding the TOS and Precedence 

€ 1 21 DF Bit Echoing with ICMP Error Messages 

!?n^ch?bit X StI UDP ^[f 9 ^ $ent to a closed UDP P° rt - to elh * an ICMP Port , 
DF ^K^^KSK-J?n? F ^ 11,6 ° ffendin9 data9ram - As It oan be seen the 

St«m Issued taS 96 FrBeBSD 41 1 machine ' Whi0h was te, 3 et 

(rootegodfather /root]# hping2 -2 -p 2000 ~c 2 -y y.y.y v 
^£L default routing interface selected (according to /v loc) 
SV'^-y y.y.y-y): udp mode set. 28 headers ? o data bytes 

™ E™"**** «»i y.y.y-y (host address) y eS 

ICMP Port Unreachable from y. y.y.y (host>ddr eS s) 

— y-y-y.y hping statistic --- 
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2 packets tramitted, 6 packets received, 100% packet loss 
round-trip min/ avg/raax = 0,0/0,0/0,0 ma 
troot®godfather /root]* 

00:31x29.805075 pppO > X.x.X,X.1403 > y .y .y .y . 2000 = udp 0 (DP) (ttl 64. 
id 19417) 

4500 OQlc 4bdg 4000 4011 452b xxxx xxxx 
yyyy yyyy 057b 07d0 0008 48C6 

00:31:30-103692 pppO < 10,170*1»79 > x.x.X.X: icmpr y.y.y.y Udp port 
2000 unreachable Offending pkt: x.x.x.x.1403 > y.y .y^y.2000 : udp 0 (DF) 

(ttl 45, id 1$417) (DF) (ttl 23B,. id 47017) 

4500 0038 b7a9 4000 eeOl 2b4e yyyy yyyy 
xxxx xxxx 0303 efa9 0000 0000 4500 001c 
4bd9 4000 2dll 582b xxxx xxxx yyyy yyyy 
057b 07d0 0008 0000 

We can distinguish between the group of operating systems, which win echo back the DF bit with 
their replies, to the group of operating systems that will not. 

The next example is with Microsoft Windows ME; 

00:43:45.853751 pppO > x.x.x.x.1580 > y.y. y.y. 10: udp 0 (DF) (ttl 64, 
id 63227) . 

4500 001c f6fb 4000 4011 730a xxxx xxxx 

yyyy yyyy 062c 000a oooa 2Sdd 

00:49i46. 173681 pppO «= 212.150 .102 .36 > x.x.x.X: icmp ■ y.y.y.y udp port 
10 unreachable Offending pxt = x.x.x.x.1580 > y.y.y.y* 10 ^ udp 0 (DF) 
(ttl S$ # id 63227) (ttl 119. id 430) 

4500 0038 oiae oooo 7701 714c yyyy yyyy 

XXXX XXXX 0303 cdel 0000 0000 4500 001c 

fefb 4000 37ii 7c0a xxxx xxxx yyyy yyyy 
062c 000a 0008 28dd 

Among the operating systems 1 have checked LINUX machines based on Kernel 2.2 jc / 2.4 jc, 
ULTRIX. Novell Netware, and Microsoft Windows 98/98SE/ME/NT4SP6A/Windows 2000 Family, 
will not echo back the DF bit with their ICMP Error messages. 

How can we distinguish between the operating systems in the non-DF echoing group? 

Since Linux Is using the value of OxcO Hex for his Precedence Bits field value for air ICMP Error 

messages we can separate it instantly. 

00:25zl7. 203727 pppO > X.X.X.X. 1421 > y ,y *y .y .2000 5 Udp 0 (DF) (ttl 64, 
id 11969) 

4500 001c 2ecl 4000 4011 b938 xxxx xxxx 

yyyy yyyy osed 07d0 0008 9fa9 

00:25:17-573698 pppO < y-y.y-y =» x.x.x.x: icmp: y.y.y.y udp port 2000 
unreachable Offending pkt: x.x.x.x. 1421 > y.y.y.y. 2000 : udp 0 (DF) (ttl 
45, Id 1196*) [tos OxcO] (ttl 236, id 30250) 

45c0 003B 956a 0000 ecOl e5c2 yyyy yyyy 
xxxx xxxx 0303 4fee 0000 0000 4500 001c 
2ecl 4000 2dll cc3B xxxx xxxx yyyy yyyy 
05Sd 07d0 0008 &Xa9 
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ULTRIX echo integrity is not that good. The offending packet echoing will set both the IP Header 
Checksum and the Original UDP Checksum to zero, it will also miscalculate the IP ID field value 
and will flip the first 8 bits with the second one, creating a false value for it: 

00 s 29 = 05.013726 pppO > x.X,X.X.liaS > y „y .y .y.2000 s Udp 0 (DF) («1 64, 
id 34921) 

4500 001c 8869 4000 4011 5f85 xxxx xxJOC 
yyyy yyyy 04a4 07d0 0008 a087 



00:29:05.383686 pppO < 194,47.250.222 > x.X.x,*= 
2000 unreachable Offending pkt : x.x.x.x. 1130 > y 
45, id 27016, bad cksunt Ot) (fcfcl 236, id 9736) 

4500 0038 2608 0000 ecOl S5da yyyy yyyy 
xxxx xxxx 0303 cle7 0000 0000 4500 001c 
698B 0000 2dll 0000 xxxx xxxx yyyy yyyy. 
04a4 C7d0 0003 0000 



icnrp: y.y.y.y udp port 
y.y.y.2o00j udp o (ttl 



This will leave us with Novell Netware and the various Microsoft Windows Operating. Systems. 

As discussed in section 6.17 "Novell Netware Echoing integrity Bug with ICMP Fragment 
Reassembly Time Exceeded when a Novell Netware operating system issue an ICMP Time 
Exceeded error message it will zero out on the echoed offending packet the IP TTL field value. 
We will use this information and send an offending packet to the questioned operating systems 
that will elicit an ICMP Time Exceeded error message from the quesitoned OSs. 



Off ending Pack at with OF Bit Set 
(data portion set to 70 bytes, for example) 
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Diagram 12: OF Bit Echoing with ICMP Error Messages 
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We can take a second approach using the ICMP Fragment Reassembly Time Exceeded error 
message. We will send an offending packet with the DF bit set that will elicit an ICMP Fragment 
Reassembly Time Exceeded error message back from the targeted machine- Novell Netware, 
LINUX based Kernel 2.2.x and 2.4x-t, and the various Microsoft Windows operating systems will 
set the DF bit with their replies. UNUX and Novell have their unique fingerprinting with ICMP 
Fragment Reassembly Time Exceeded error messages* enabling us to Isolate the Microsoft 
based operating systems machines. 



HP-UX 11 jc based machines will have a unique behavior when the PMTU discovery process 
based on ICMP Echo Requests is enabled (by default). In the next example I have sent a UDP 
datagram to port 53 (DNS) of the targeted HPUX machine. 

[root@godfather /root]# hping2 -2 53 -c .2 -y y.y.y.y 
pppO default routing interface selected (according to /proc) 
HPtUG y.y.y.y. (pppO y-y-y-y) : udp mode set, 28 headers + 0 data bytes 
ICMP Port Unreachable from y*Y-y*y (unknown host name}" 
icmp Port Unreachable from y.y.y.y (unknown host name) 

. y-Y-y-y hping statistic — 

2 packets traraitted, 0 packets received, 100% packet loss 
round- trip min/avg/max = 0. 0/0.0/0.0 ms 
[root@godxather /root]# 



00 ;45: 02.490445 pppO > x.x.x.x.codasrv > y.y.y.y. domain: 0 [OqJ (0) 
(DP) (ttl 64, id 7454) 

4500 001c Idle 4000 4011 e70fl aoooc xxxx 

yyyy yyyy osso 0035 oooe bf7e 

As an instant reply the PMTU discovery process which is based upon ICMP Echo request(s) is 
started: 

00:45: 03. 113GQ6 pppO < y.y^ Y*Y > x.x.x.x: icmp; echo request (t)P) (ttl 
242, id 25153) 
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My LINUX machine replied with ICMP Echo Reply: 

00:45:03.113767 pppO =» x.x-x*x > y*y^y*y = icioap: ec&o reply (ttl 25$, icl 
98) 
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0000 0000 0000 00O0 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 

The first ICMP Port Unreachable error message arrives without the DF bit set 

00 = 45:03. 123^52 pppO < y.y.y.y > x.x.x.x: icrap: Y*y*Y*Y udp port domain 
unreachable offending pkt= x.x.x.x.codasrv > y-y-y-y- domain: 0 [Oq] (0) 
(DF) (ttl 51, id 7454) (ttl 242, id 25154) 

4500 0038 €242 oooo fsoi 2fds yyyy yyyy 

xxxx xxxx 0303 33cl 0000 0000 4500 001c 
idle 4000 3311 f40B x?otx xxxx yyyy yyyy 

0980 0035 0008 bf7e 

A second UDP datagram is sent 

00:45:03.493752 pppO > x.X.X.X.COdasrv-se > y.y.y.y. domain:. 56810+ (0) 
(DF) (ttl 64, id 59904) 

4500 001C ea00 4000 4011 13-26 xxxx xxxx 

yyyy yyyy 0981 0035 0008 bf7d 

The ICMP Port Unreachable error message that was sent for the second UDP datagram now sets 
the DF bit as part of the PMTU discovery process maintenance: 

00:45:03.813687 pppO < y.y.y,y > x.x.x.x: icrap : y-y-y-y udp port dotoain 
unreachable Offending pkt: x.x.x.x.codasrv-se > y.y.y.y .domain: 2S930 
op5+ [b2&3~0x2d61] [29188a] [2570Oq;J [2494Gn] [28769au] (0) (DF) (ttl 
51, id 59904) (DF) (ttl 242, id 25155). 

4500 0039 6243 4000 f20l efd6 yyyy yyyy 

xxxx xxxx 0303 33C1 0000 0000 4500 QOlc 
eaoo 4000 3311 2726 xxxx xxxx yyyy yyyy 

0981 0035 0008 bf7<i 

This also means that with the regular behavior with HPUX 1 1 jc it will not echo back the DF bit 
Also, if you are sending only one offending datagram to the targeted HPUX 1 1.x based machine, 
you will not be able to see the change. 

So how can we distinguish HPUX from the other operating systems? 

HPUX based operating system(s) machines will echo up to 64 bytes Of the offending packet's 
data portion. By sending a bigger offending datagram (for example with 8D bytes of date portion) 
we can examine which of the operating systems in question, which do not set the DF bit with the 
ICMP error message, will echo 64 bytes of the data portion (or even more than 8 and will not set 
the the precedence bits to OxcO). 



Not that useful fingerprinting method(s) 
6.22 Unusual Big ICMP Echo Request 

What would happen if we would send unusual big ICMP Echo message that would require Its 
fragmentation? Would the queried operating systems will process the query correctly and 
produce an accurate reply? 



[rootOaik /rootJ# ping -s 1500 x.x.x.x 

112 

Copyright & Oflr Aridn. 2000-2001 
htip^/www.sv5-securitv,cx3m 



898-d 803/99 Id BU-i J ee^uo s | q ' s ue ^ j e H ■ eqqo u>|-ujo J j iudz():go K)-0£-90 



f) 



k-9!i:(ss-iijui) Nonvsna .mseaueH^aiso ,90cc/8:siNa .wt-dtiKda'Oidsnws . [suu iMEi^a ujsiso] wd »«ao«:i9 ivaAaa , scenes 39tfd 

O ' ■ . f> 



ICMP Usage in Scannmg 
Version 2.5 

PING x.x.**x (x.x.x.x) from y.y-y.y : 1500(1528) bytes of data. 

1508 bytes from x.x.x.x: icmp — seq=Q ttl=»241 fcime=1034.7 ,ms 

150S bytea f roni host_address Tx-x.x.x) : icmp_seq»2 ttl=241 time=1020,0 

xm 

1508 bytes f rom hostjaddress (x.X.X.X) ; icmp_seq=3 «1^241 time-1090 . 4 

IDS 

1508 bytes from hdst_addrees (x.x.x.x): icmp_seq«5 ttl=241 time^lOGO.O 
ns 

x.x.x.x ping statistics 

8 packets transmitted, 5 packets received, 37% packet loss 
round-trip min/avg/max = 1000.2/1041.0/1090.4 ma 
[root®aik /root]* 

As it seems atl the probed operating systems I have tested behaved correctly processing the 
query and sending the reply back. 

What else can assist us with this kind of query? 
The DF {Donl Fragment) bit. 

Some operating systems would process the query and set the don't fragment bit on the fragments 
of the reply tike we have outlined In the "DF Bit Playground" section. These operating systems 
would be Sun Solaris, and HP-UX 10.30 *V 11.0X 49 . 

We can use other methods, which does not generate the kind of noise this method generates. 
Basically there is no reason for this size of ICMP Echo request- This shoutd trigger IDS systems 
immediately that something suspicious Is happeningv 



Please refer to section 6,2 tor mora Information. 
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7.0 Filtering ICMP on your Filtering Device to Prevent Scanning Using ICMP 

7.1 Inbound 

An example of incoming ICMP traffic that should be blocked in order to prevent scanning 
techniques that were outlined in tfws paper might be: 

• ICMP Echo (used for Host Detection, traceroute. Inverse Mapping, and Operating 
System Fingerprinting) * 

• ICMP Echo Reply (used for Inverse Mapping) 

• ICMP time Stamp Requests (used for Host Detection, Operating System 
Fingerprinting) 

• ICMP Address Mask Request (used for Host Detection, Operating System 
Fingerprinting) 

• All ICMP Message Types (Inverse Mapping Technique) 

• ICMP Error messages (Operating System Fingerprinting) 

• All ICMP Message Types should be blocked in order to prevent the fingerprinting 
. techniques I have outlined in this research paper. 

• You should also block the IP directed broadcast on your border router, 

- Deny access to your Broadcast and Network addresses from the Internet 

If you look closely at this list it is all ICMP Message types, whether query types or error types. 

7.2 Outbound 

There are people who claim that any traffic type of ICMP should be allowed from a protected 
network to the Internet This Is not true. Filtering the incoming traffic does not mean we are 
protected from some of the security hazards I outlined Jn this paper, 

7.2.1 ICMP ECHO Reply (Type 0) 

Used to map a host using Host Detection. 

7.2.2 ICMP Destination Unreachable Messages 

I have demonstrated that host detection can be done with bad IP Header packets, which elicit 
various ICMP Parameter Problem and ICMP Destination Unreachable error messages from the 
probed machines and draw the attacked network topology. 

7.2;3 ICMP "Fragmentation Needed and Don't Fragment Bit was Set" 

See section 3.5 



72A ICMP ECHO (Type 8) ^ . , .*u • 

We have to have a Stateful filtering device that would perform Stateful inspection with ICMP in 
order to let ICMP ECHO Requests out, and receive only the corresponding ICMP ECHO Replies. 

The current "state with filtering devices is not that bright. Most of them do not perform Stateful 
inspection with the ICMP protocol. Allowing ICMP ECHO Replies inside our protected network is 
very dangerous and is not worth it. 

Unless you use a Stateful filtering device with the ICMP protocol don't let ICMP ECHO Replies 
into your protected network. This would make your requests useless so you better block them. 
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7.2.5 ICMP Time to Live Exceeded in Transit (Type 11 Code 0) . 

To eliminate traceroute and Reverse Mapping techniques we do not want to let a Time-to-Llve 
Exceeded code 0 messages go back to the malicious computer attacker . 

7.2.6 ICMP Fragmentation Reassembly Time Exceeded (Type 11 Code 1) 

By blocking this ICMP type we eliminate the usage of a Host Detection technique, which sends 
only few fragments, form a fragmented datagram, and force the probed host to send us an ICMP 
Fragmentation Reassembly Time Exceeded error message back revealing his existence. 



7.2.7 ICMP Parameter Problem 

We have demonstrated that host detection can be made with bad IP Header packets, which 
would elicit various ICMP Parameter Problem and ICMP Destination Unreachable error 
messages from the probed machines. 

7.2.8 ICMP Time Stamp Request & Reply , 
Time Stamp requests & replies can be used for Host Detection and Inverse- Mapping. 



7.2.9 ICMP Address Mask Request and Reply 

Address Mask request & reply can be used for host detection and inverse Mapping. 

7.2.10 The liability Question ^ u. , 

System administrator / Network administrator don't want to be held liable for an attack generated 
from there network by an abusive user (or a malicious « m P^^ c ^ sl ?9 a STSS^S 
system wllhin the network). Therefore blocking some types of ICMP traffic from the protected 
network to the outside world is recommended for liability reasons: 

o Destination Unreachable Codes 2^4 

o ICMP Destination Unreachable error messages 2-4 ("Port Unreachable", 
-Protocol Unreachable" and "Fragmentation Needed and DF Hag was. Set*) is a 
group of messages that are hard error conditions and when received Should 
terminate a connection. 

This allow an attacker to send fake Destination Unreachable codes 2-4 to 
terminate valid connections between the attacked target and other hosts on the 
void. 

Old TCP/IP implementations terminatTCP connections when i ^tag 
those error messages. Modern TCP/IP irnplementat.ons no longer terminate a 
TCP connection when receiving those error messages 

o Source Quench messages 

o Since hosts still react to Source Quenches by stowing communication, they can 
be used as a Dental-of-Service measure. 

o Redirect messages 

0 , f wu forae |C MP Redirect packets, and if your target host pays attention to 
^-l^rSS* may be employed for denial of service attacks, where a 
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host sent a route that loses it connectivity, or is sent an ICMP Network 
Unreachable packet telling it that it can no longer access a particular network. 

This means that all outbognd ICMP traffic should be disallowed. 

JtS^^m^Sf ICMP faring rule* with your R-MM I suggest 
«TbtaS J ln«*Snc I ICMP Lffic except for Type 3 Code 4. which Is used by the Pa* MTU 
££££ S«SS ICMP Type 3 CodT4 should be allowed from the Internet to yourDMZ at 
Kt Opening your Internal segmentation to this kind of fraffic Is ^^! in ^ n dependS °° 
the facilities /Icflvlties / usage of the site and the level of filtenng you w.sh to maintain. 

if you will block incoming ICMP -Fragmentation Needed and Don't Fragme ntl BIT ^ SeT your 
nelwork performance will suffer from degradation. You should understand the secunly nsks 
i^Mm^Sg this kind of traffic to your DM2 (& protected nelwork) - The of a 

SSK-SerS. Inverse Mapping. Host Detection, and a oneway Covert communication 
channel (which was not been'seen in the wild yet). 

Another consideration could be the usage of network ^^^^^J^SS^ 
and ping- In the case of traceroute if the filtering device you are us.ngdoes rwtsupport Steteful 
hTspecfion with ICMP than allowing ICMP TTL Exceeded In Tran S ,t(T^1^ code 0) error 
m^aaes Inside the protected network could lead to vanous security hazards The same goes 
S£SR«0 reply is even more dangerous when allowed inside the protected 
network (Inverse Mapping. Covert Channel and more security nsks). 

You can limit the number of systems thatneed to use fte "^^f'^Ste SlvTe tin^V 
but bear in mind that those systems could be mapped from the Intemet-and this is only the ftp or 

the iceberg. 

internal Hgstte ) performance considerations - When blocking incoming ICMP 

Unreachable NeLjrk^ost^roto^PortU ^reachable ICMP error messages coming from the 

KeS^s?S3dhS I wtinthe destination system's network fe unreachable/when a host 

machine is closed. Thecal, would hangup* the ^i^gSgS n^es tosS^your 
Inconveniently is better than having the dangers other types of ICMP error messages ms.ce your 

network can introduce. 

Unless your filtering device is a real intelligence one. doing his work with dynamic tables and 
C^^conW the ICMP replies with the requests, do not open your Internal network 
segment to no ICMP traffic type. 

Some might offer to use a Proxy server wilh the ICMP P^ be^een the Internet and you 
protected I networks). A Proxy Server Is only a tunnel - remember that 



» see Appe^ B: Tr^nta.lan N«wJed but ft. 0*1 Fr^t Bit was ^ andlhePalh MTU Discovery P^, 
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lntwnet 

Incoming ICM? Truffle 
Mono 





OlHs^B tCWP Traffic 



Irlomol •> DMZ 
Incoming tCMPltafflQ 



iyp<i3 c«» None 
MUI Dfccuvary process. 



DtoatitUr* 

Ektst rates Tlata Ftwf 



• You ca^hBvp a d«dk*i«i Un*Q*mm* iftat ¥outd be aflowod to too IC VP for 

topodlM/ Dynamic rtanflL Thto nwami in« no Imaming IC»» k ^ISllXl!? 

ftiauon, uniKts H» collated with a pfuvlcw* ICM* quwy thto imcM™ 



- If a maJIckW* wmpulor nttaCRftf bmata InlO Uw DliC you do not VwtfM to provide hkrt tlw 
s toucan internal m«shm88 & and theaDWy to oimiy HvomdhracWy. 



Figure 14: Firewall ICMP Filtering Rules 



7 A Other Problems - Why it is important to filter ICMP traffic in the Internal 
segmentation 

Consider the following realistic scenario: 

You have an Internal segment built with Microsoft based operating system machines (for ttie sake 
of the example only). A malicious computer attacker might Bend you a Trojan that w^Ho^ 
detection and/or mapping capabilities. It win be hidden in an.Emad message (eWher as a^hment 
or some other thing) a naive user will open. After activation rt will start to map internal hosts and 
internal segments and send the information back to the malicious computer attacker. 

What will be the easiest method in order to map internal host(s)? Ping them. 

How many of you reading this research hav* -management segment©- that are allowed to use the 
Ping utility In order to verify that some Hosts are alive? 

If something like this Trojan gets its way to this segment than probably your entire internal 
networking infrastructure (or the Important part of it) will be revealed. 

Some one might think that strong filtering or a 9^^^ ^^^Z^ 

people separating their work environment to more than two or * r ^J?^ 

use ttfe Email, and need to surf the web... (good ways to send the collected Information out). 

Mysuggestionfe to configure internal host(s) not to answer ^^^^^.P^^j^^Tw^^^^^^ 
should not answer for. I would restrict this to the maximum and not allow .ntemal hosts to be 
queried with any ICMP Query message type. 
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Back to our monitoring problem - If you need to maintain management/m^^^^ 
thanl would suggest Storing the traffic in both ways from the management stations to the - ~ 
Tn^T^^n a way it would not be possible to simply query ^^^Sg^ ' 
Steful nSng with ICMP). Use a dedicated system for the querying and block the other 
machines In the management segment from doing so. 



Outbound JCJiflP tndfic 

Ono system should to conflgimtf 
ttragh thb sravMintmnna rules la 
h&vo afcflily to qunry macWna« 
an ths Secvn S«rvk»s aognwnlwih 

SAOum £«vk»a sc^natrt nhoufcJ ba 
9 -Wfltful FkrrtttJT **** botpactt «h« 




DM2 b not tfn**eA to have vatic 



Figure 15: Internal segmentation ICMP Filtering Example 



block every thing: For example, ICMP error messages the firewall generates tor venous 
Some firewalls wUl hold a certain porton 

underlying protocoTs ^r^^^^gJJX Firewalls has the 
SgSrprinS operating system, which the firewall software is installed on. 
WewIHgatoanexIreme^^ 

when you configure your firewall's rule base. The first is 10 aeny *i iy 
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and the second would be to deny any error messages (or other conditions s" 0 * 1 TCP 
etc.) that might help a malicious computer attacker in his tasK to fingerprint the Firewall itself. 
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8.0 Conclusion 

The ICMP protocol is a very powerful tool In the hands of smart malicious computer attackers. 
Mapping, detecting, and fingerprinting of hosts and networking devices can be done in various 
ways as 1 have outlined in this paper: 

It is extremely important to understand that ICMP traffic can be used for other malicious activities 
other than scanning, such as; 

• Denial of Service Attacks 

• Distributed Denial of Service Attacks 

• Covert Channel Communications 

Therefore filtering Inbound and Outbound ICMP traffic is very important and may help you In 
preventing risks to your computing environment 
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Appendix A: The ICMP Protocol 51 

Internet Control Message Protocol (ICMP) is used for two types of operations: when a router or a 
destination host need to inform the source host about errors in a datagram processing, and for 
probing the network with request messages in order to determine general characteristics about, 
the network (getting the information back, hopefully, with the reply messages). 

Some of lCMP"s characteristics are: 

o ICMP uses IP as if it were a higher-level protocol, however, ICMP Is already an internal 

part of IP, and must be Implemented by every IP rjiodule. . 
o ICMP is used to provide feedback about some errors in a datagram processing, not to 

make IP reliable. Datagrams may still be undelivered without any report of their loss. If a 

higher level protocol that use IP need reliability he must implement it, 
o No ICMP messages are sent in response to ,CMP messages to avoid infinite repetitions- 

The exception is a response to ICMP query messages (ICMP Types 0,8-10,13-18. See 

Table 1 1CMP Query Messages), 
o For fragmented IP datagrams ICMP messages are only sent about errors on fragment 

zero (first fragment). * • 

o ICMP error messages are never sent in response to a datagram that Is destined to a 

broadcast or a multicast address* 
o ICMP error messages are never sent in response to a datagram sent as a link layer 

broadcast . 
o ICMP error messages are never sent in response to a datagram whose source address 

does not represents a unique host - the spurce IP address cannot be zero, a toopbsck 

address, a broadcast address or a multicast address, 
o ICMP Error messages are never sent In response to an 1GMP massage of any kind, 
o When an ICMP message of untoiown type Is received, it must be silently discarded. 
o Routers will almost always generate ICMP messages but when it comes to a destination 

host(s), the number of ICMP messages generated is implementation dependent. 




, ICMP Query Messages 



ICMP error Messages 



Echo 

Router Advertisement 
Router Solicitation 
Time Stamp 
Information 
Address Mask 



Destination Unreachable 
Source Quench 
Redirect 
Time Exceeded 
Parameter Problem 



Table 16: ICMP message types 
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A.1 ICMP Messages mL t M nrMm mA 

ICMP messages a£ sent in IP datagrams. The protocol number will be always one (ICMP), and 
the Type-of-Service will be zero. The IP data field will contain the actual ICMP message: 



IP Data 
fluid 



'4 bit 
Vowton 


4H 
NN*r 


B-bUiypooC tendon 
(TOSH? 




16-bft total !i*td1M in byte*) 








3DTt 




(Tn.) 








32-M dMfltiaflon V addrtM 






Oprtntm(rimy) 




Typ* 


CD* 


ChMksum 


! 
\ 
i 




ICMP dab (dopondta 




i 
i 

j 



I 



4 byte* 



Figure 16: ICMP Message Format 



wSnSSflUd^ the internet (.P) Header and * fcrt*. first 8 data octets 
SJofthe datagram *at triggered the error, more than 8 octets (bytes) may be sent; th,S 
header and data must be unchanged from the received datagram. 

■mo tvpp fipiH trifles the tvoc of the message, while the error code for the datagram reported 
on bylKMP 2SS3l» the <&» field. The code interpretation Is dependent 

upon the message type. 
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Type; 



0 
1 
2 
3 



4 
5 



6 

7 

8 

9 

10 

11 



12 



13. 
14 



Name. 



Echo Reply 
Unaligned 
Unasskjned 

Destination Unreachable 5 * 



Source Quench 
Redirect 



Alternate Host Address 
Unasslgned 
Echo Request 
Router Advertisement 
Router Selection 
Time Exceeded 



Parameter Problem 



Tlmestarnp 
Ttmestamp Reply 



Code 



0 No Code 



Q Net Unreachable 

1 Host Unreachable 

2 Protocol Unreachable 

3 Port Unreachable 

4 Fragmentation Needed and Don't 
Fragment was Set 

5 Source Route Failed 

6 Destination Network Unknown 

7 Destination Host Unknown 

8 Source Host Isolated 53 

9 Communication with Destination 
Network is Administratively Prohibited 

10 Communication with Destination Host is 
Administratively Prohibited 55 

11 Destination Network Unreachable for Type of 

Service. 

12 Destination Host Unreachable for 
Type of Service. 

13 Communication Administratively Prohibited. 

14 Host Precedence Violation . 

15 Precedence cutoff in effect 
0 No Code 

0 Redirect Datagram for the Network {or subnet) 

1 Redirect Datagram for the Host 

2 Redirect Datagram for the Type of Service and 
Network 

3 Redirect Datagram for the Type of Service and 
Host 

0 Alternate Address for Host 

0 No Code 
0 No Code 
0 No Code 

0 Time to Live exceeded in Transit 

1 Fragment Reassembly Time Exceeded 

0 Pointer Indicates the error 

1 Missing a Required Option 

2 Bad Length 
0 No Code 

0 No Code . 



K RFC 972 defines codes 1-S. RFC 1122 defines codes <M2. RFC 1B12 defines codes 13-15. 
53 Reserved for use by U-S. miliary agencies. 
Reserved for use by U.S. mifitary agencies. 
5 Reserved for use by U.Q. military agencies. 
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Type 



15 
16 
17 
18 
19 

30 
31 
32 
33 
34 
35 
36 
39 
40 



Name 



Information Request 
Information Reply 
Address Mask Request 
Address Mask Reply 
Reserved (for Security) 



Codb 



No Code 
No Code 
No Code 
No Code 
No Code 



20-29 reserved (for Robustness Experiment) 

Traceroute 

Datagram Conversion Error 
Mobile Host Redirect 
IPv6 Where-Are-You 
IPv6 l-Am-Here 
Mobile Registration Request 
Mobile Registration Reply 
SKIP 
Photuris 



0 Reserved 

1 unknown security parameters index 

2 valid security parameters, but authentication 
failed 

3 valid security parameters, but decryption failed 



Table 17: ICMP Types & Codes 

Checksum - contains the 16b»t one's complement of the pne's complement sum of the ICMP 
• starting with the ICMP Type field. For computing this checksum, the checksum field * 

assumed to be zero. 



Data 



. With ICMP error messages it will contain a part of the original IP message for wh,ch this 
SJp message vSs generated. The length of the DATA field equals the IP ftegram 
S lesTthe IP header length. Every ICMP' error message Includes the Internet (IP) 
Sd^and'S feasfme first 8 data octets (bytes) of the datagram ** ta 99°^* e J^ 
more than 8 octets (bytes) may be sent; this header and data must be unchanged from 
the received datagram, 

- With ICMP query messages the Data field will contain dependent information upon the 
query type. 



£ M P ^SSSSHSL report a problem that prevented deHvery.The nature of the 
problem should be a norvtranslent delivery problem. 
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TVpa 




Ctockstpn 




Unused 


IP head* ♦ fi4 Mb of Qi&m dam of tho diagram 



31 



Figure 17: ICMP Error Message General Format 



ICMP error message length 

Every ICMP error message Includes the IP Header (20 to 60 bytes) and a* teas* the first 8 data 
bytes of the datagram that triggered the error; more than 8 bytes may be sent this header and 
data must be unchanged from the received datagram. 

AN ICMP error message length should be between ^6 to 72 bytes. 

The ICMP Protocol Rules for ICMP Error Messages 

* ICMP Error messages are not sent for another ICMP Error message to prevent Infinite 
loops. 

* ICMP error messages are never sent in response to a datagram that is destined to a 
broadcast or a multicast address. 

* ICMP error messages are never sent in response to a datagram sent as a link layer 
broadcast ^ 

* ICMP error messages are never sent in response to a datagram whose source address 
does not represents a unique host - the source IP address cannot be zero, a foopback 
address, a broadcast address or a multicast address* 

- ICMP Error messages are never sent In response to an IGMP massage of any Kind. 

A.1.1 ICMP Error Messages 56 

• Destination Unreachable (Type 3) 
m Source Quench (Type 4) 

• Redirect (Type 5) 

• Time Exceeded (Type 11) 

• Parameter Problem (Type 12) 

A.1.1.1 Destination Unreachable (Type 3) 

ICMP Destination Unreachable message type issued by a D ^^^"°^f . 
A destination host issues a destination unreachable message when the protocol specified in the 
protocol number field of the original datagram Is not active on the destination host, or tne 
specified port Is inactive. 

ICMP Destination Unreachable message type Issued by a Routen 



56 Some of the worfrtfl In this section are direct quotes from RFC 792 available from m^ ^^^Mtfc^M . 
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ICWP Usage In Scanning 
Version 2.5 

A roofer Issue a destination unreachable message in response to a packet that it cannot forward 
because the destination (or next hop) is unreachable or a service is unavailable. 



Code 



Meaning 



0 
1 



4 

5 
6 

7 
8 
9 

10 

11 
12 
13* 
14 



Network Unreachable 
Host Unreachable 

Protocol Unreachable 

Port Unreachable 



Fragmentation needed and 
DF flag Set 
Source Route Failed 



Destination 
Unknown 



Network 



Destination Host Unknown 

Source Host Isolated 

Communication with 
Destination Network is 
Administratively Prohibited 
Communication with 
Destination Host is 
Administratively Prohibited 
Network Unreachable for 
Type of Service 

Host Unreachable for Type of 
Service 

Communication 
Administratively Prohibited 

Host Precedence Violation 



Explanation 



Generated by a router if a route to the destination 
network is not available. 

Generated by a router if a route to the destination host 
on a directly connected network Is not available (does 
not respond to ARP)- 

Generated if the transport protocol designated in a 
datagram fe not supported in the transport layer of the 
final destination. 

Generated if the designated transport protocol (e.g. 
UDP) is unable to demultiplex the datagram in the 
transport layer , of the final destination but has no 
protocol mechanism to inform the sender. 
Generated if a router needs to fragment but cannot 
since the DF flag Is set 

Generated if a router cannot forward a packet to the 
next hop in a source route option. 
According to RFC 1812 this, code should not be 
generated since it would imply on the part of the router 
that the destination network does not exist (net 
unreachable code 0 should be used instead of code 6). 
Generated only when a router can determine (from link 
layer advice) that the destination host does not exist 
Generated by a Router if it have been configured not to 
forward packets from source. 

Generated by a Router if it has been configured to 
block access to the desired destination network. 

Generated by a Router if it has been configured to 
block access to the desired destination host 

Generated by a router if a route to the destination 
network with the requested or default TOS is not 
available- 

Generated if a router cannot forward a packet because 
Its route(s) to the destination do not match either the 
TOS requested in the datagram or the default TOS (0). 
Generated If a router cannot forward a packet due to 
administrative filtering (ICMP sender Is not available at 
this time). 

Sent by the first hop router to a host to Indicate that a 
requested precedence is not permitted for the particular 
combination of source/destination host or network, 
upper layer protocol, and source/destination port 
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Code 


Meaning 


expterialiori - ' t .'\ , \'' t 


15 


Precedence cutoff in effect 


The network operators have imposed a minimum level of 
precedence required for operation, the datagram was 
sent with precedence below this level. 



* Routers may have a configuration option that causes code 13 messages not to ^ generated. 
When this option is enabled, no ICMP error message te sent .n r^ponse to a packet that .s 
dropped because irs forwarding is administratively prohibited. Same Is with type 14 & 15. 

Table i 8: Destination Unreachable Codes (Router) 

The only type of ICMP Destination Unreachable error message, which Istfgntty different from the 
other, is Type 3 Code 4 - Fragmentation Needed but the Don't Fragment Bit was.set 



16 



31 



-Typo Co** 






4byto5 


Unused 


UrvkMTU 




4 bytes 


IP hwtJpr * 64 bits of alata! *aa of Itw t*a*aywn 





Figure 18: ICMP Fragmentation Needed but the Dont Fragment BR was set Message Format 

The Unused field will be 16 bits in length. Instead of 32 bits, with ^^H'^^UZ^t 
the Tl6 bite will be used to carry the MTU used for the link that could not defiver the ^ ito 
L next hop (or destination) because the size of the datagram was too big to cany. Smce 
datagram eoUd not be fragmented (the DF Bit was set) an error messaged *•""<* to the 
sender indicating that a lower MTU should be used, hinting the s.ze of the next hops links. 

A.1 .1 .2 Source Quench (Type 4) 

ICMP Source Quench message type Issued by a Router. 

S?£S -send* tS messaged means that the router does not have £^-££~ dBd tD 
queue the datagrams for output to tha next network on the route to the destination network. 

RFC 1812 specify that a router should not generate Source <^J""5<£ ^"ft Te 
does originate Source Quench message must be able to imrt the rate ^J"^™* ^ 
gentratS (bLuse it consumes bandwidth and it is an Ineffective anhdote to congestion). 

A router receiving an ICMP Source Quench message type: 
When a router receives such a message it may ignore it 

arrive too fast to be processed. The ICMP source quench message Is a request to the host to cur 
back the rate, which it is sending traffic to the Internet destination. 

12B 
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The ICMP header code would be always zero. 



Host receiving an ICMP Source Quench message type: t^d 

An ICMP Source Quench message must be reported to the transport layer, UDP or TCP, the host 

should throttle itself back for a period of time, than gradually increase the transmission rate agam. 

A.1-1.3 Redirect CType 5) 

ICMP Redirect message type Issued by a Router. , rarTicfrtrthrt 

If a router generates this message, it means the host Should send future datagrams for frte 

netStotho router who's IP is given in the ICMP message The ™^ 

same subnet as the- host who sent the datagram and the router that generated the ICMP redirect 

message. 

A routing loop is generated when the router IP address matches the source IP address in the 
original datagram header. 

Routers must not generate a Redirect Message unless a// the following conditions are met 

o The packet is being forwarded out the same physical interface that 
H was received from, 

o The IP source address in the packet is on the same Logical IP 
(Sub) network as the next-hop IP address, and 

o The packet does not contain an IP source route option. 



31 



Type 


Cbdft 


Checksum 


-3 


kbytes 

5- 




Router IP atffett 




4 bytes 


!P bra** + 64 Wt4 ctf original data of the daiauwn 







Figure 19: ICMP Redirect Message Format 



A router receiving an ICMP Redirect message type: h «ih«* router If 

A router mav ionore ICMP Redirects when choosing a path for 3 packet onglnated by the router tt 
iSSTlTSS^rlSm Protocol or if forwarding is enabled on the router and on the 
interface over which the packet is being sent 

Four different codes can appear in the code field: 



Code 



Meaning 



Redirect Datagram for the Network (or subnet) 
Redirect Datagram for the Host 
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Code. 


Meaning . - - 

'". - • • . . * * * : 
- . • . • •' ; ■ v • • * 


2 
3 


Redirect Datagram for the Type of Service and Network 
Redirect Datagram for the Type of Service and Host 



Table 19: Redirect Codes 



ICMP Redirect message type issued by a Host: 

A host should not send an ICMP Redirect message. Redirects are to be sent only by routers* 



Host receiving an ICMP Redirect message type: 

A host receiving a Redirect message must update its routing Information accordingly. Every host 
must be prepared to accept both Host and Network Redirects. 

The Redirect message should be silently discarded with the following cases: 

o The new gateway address it specifies is not on the same connected (sub-) net through 

which the Redirect arrived, 
o If the source of the Redirect is not the current first-hop gateway for the specified 

destination. 



A. 1 A A Tiriie Exceeded (Type 11) 

ICMP Time Exceeded message type Issued by a Router 

If a router discovers that the Time-To-Live field in an IP header of a datagram he process equals 
zero he will discard the datagram and generate an ICMP Time Exceeded Code 0 - transit TTL 
expired (this can also be an Indicator of a routing loop problem). 

When the router reassemble a packet that is destined for the router, it is acting as an Internet 
host. Host rules apply also when the router receives a Time Exceeded message. 

A router must generate an ICMP Time Exceeded message code 0 when it discards a packet due 
to an expired TTL field. A router may have a per-fnterface option to disable origination of these 
messages on that interface, but that option must default to allowing the messages to be 
. originated. 

IQMP Time Exceeded message type Issued by a Host: 

If a host cannot reassemble a fragmented datagram due to missing fragments within its time limit 
it will discard the datagram and generate an ICMP Time Exceeded Code t - reassembly TTL 
Exceeded. 



A.1. 1.5 Parameter Problem (Type 12) 

ICMP Parameter Problem message is sent when a router {must generate this message) or a host 
(should generate this message) process a datagram and finds a problem with the IP header 
parameters. It Is only sent if the error caused the datagram to be discarded. 

The Parameter Problem message Is generated usually for any error not specifically covered by 
another ICMP message. 
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ICMP Usage In Scanning 

If code 0 is used, the pointer field will point to the exact byte in the original IP Header, which 
caused the problem. 

Three different codeG can appear in the code field: 



Codes 


Meaning- ' ' 


0 


Pointer indicates the error (unspecified error) 


1 


Missing a Required Option 


2 


Bad Length 



Tabfe 20: Parameter Problem Codes - 



Receipt of a parameter problem message generally indicates some local or remote 
Implementation error. 



0 4 6 16 31 



Type 






-5 


4bytes 

6- 

4bytes 


Pointer 


Uhlttod 


IP header + $4 bft$ trf ttrltfral data td the datagram 





Figure 20: ICMP Parameter Problem Message Format 
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Appendix B: ICWIP "Fragmentation Needed but the Don't Fragment Bit was 
set" and the Path MTU Discovery Process 

When on© host needs to send data to another host, the data is transmitted In a series' of IP 
. datagrams. We wish the datagrams be the largest size possible that does not require 
fragmentation along the path from the source host to the destination host 

Fragmentation by the IP layer raises few problems: 

o If one fragment from a packet is dropped, we need to retransmit the whole 
packet 

o Load on the routers, which needs to do the fragmentation, 
o Some simpler firewalls would block all fragments because they do not contain the 
header Information for a higher layer protocol needed for filtering. 

The Maximum Transfer Unit {MTU) is a link layer restriction on the maximum number of bytes of 
data in a single transmission. The smallest MTU of any link on the current path between two 
hosts is called the Path MTU. 



B.1 The PATH MTU Discovery Process 

We use the Don't Fragment Bit Flag in the IP header to dynamically discover the Path MTU of a 
given route: The source host assumes that the PMTU of a path is the known MTU of its first hop 
He win send all datagrams with that size, and set the Don't Fragment Bit If along the path to the 
destination host, there is a router that needs to fragment the datagram in order to pass It to the 
next hop, an ICMP error message (Type 3 Code 4 "Fragmentation Needed and DF set 1 ) will be 
generated, since the Don't Fragment bit was set When the sending host receives the ICMP error 
message he should reduce his assumed PMTU for the path. 

The process can end when the estimated PMTU is tew enough for the datagrams not to be 
fragmented. The source host itself can stop the process if he is willing to have the datagrams 
fragmented in some circumstances. 

Usually the DF bit would be set in all datagrams, so if a route changes to the destination host, 
and the PMTU is lowered, than we would discover it 

The PMTU of a path might be increased over time, again because of a change In the routing 
topology. To detect it, a host should periodically Increase its assumed PMTU for that link* 

The Hnk MTU field in the ICMP "Fragmentation Needed and DF set* error message, carries the 
MTU of the constricting hop, enabling the source host to know the exact value he needs to set the 
PMTU for that path to allow the voyage of the datagrams beyond that point (router) without 
fragmentation. 



B.2 Host specification 

A host must reduce his estimated PMTU for the relevant path when he receives the ICMP 
"Fragmentation Needed and the DF bit was sef error message. RFC 1191 does not outline a 
specific behavior that fe expected from the sending host, because different applications may have 
different requirements, and different Implementation architectures may favor different strategies. 



sa RFC 1191, htto:/MwwJetf. CTP /rfcfrfMi»i ivt i Mogul. S. Deering. 

Whan we send a packet that it is too large to be sent across a Knk 03 e single unft, a router needs to slice/split the 
packet into smaller parts, which contain enough Information for the receiver to reassemble them. This is called 
fragmentation. 
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The only required behavior is that a host must attempt to avoid sending more messages with the 
same PMTU value in the near future. A host can either cease setting the Don't Fragment bit in the 
IP header (and allow fragmentation by the routers in the way) or reduce the datagram size. The 
better strategy would be to lower the message size because fragmentation will cause more traffic 
and consume more Internet resources. 

A host using the PMTU Discovery process must detect decreases In Path MTU as fast as • 
possible. A host may detect increases in Path MTU, by sending datagrams larger than the current 
estimated PMTU. which will usually be rejected by some router on the path to a destination since 
the PMTU usually will not increase. Since this would generate traffic back to the host, the check 
for the increases must be done at Infrequent intervals. The RFC specify that an attempt for 
detecting an Increasment must not be done less than 10 minutes after a datagram Too Big has 
been received for the given destination, or less than 2 minute after a previously successful 
attempt to increase. 

The sending host must know how to handle an ICMP "Fragmentation Needed and the DF bit was 
set" error message that was sent by a device who does not know how to handle the PMTU 
protocol and does not include the next-hop MTU in the error message. Several strategies are 
available: 

■ Th ^f MTU should be set to the minimum between the currently assumed PMTU and 
576 s . The DF bit should not be set in future datagrams for that path. 

• Searching for the accurate value for the PMTU for a path. We keep sending datagrams 
wfth the DF bit set with lowered PMTU until we do not receive errors. 

A host must not reduce the estimation of a Path MTU value below 68 bytes. . 

A host MUST not increase its estimate of the Path MTU in response to the contents of a 
Datagram Too Big message. 

B.3 Router Specification 

When a router cannot forward a datagram because it exceeded the MTU of the next-hop network 
and the Dont Fragment bit vves set. he is required to generate an ICMP Destination Unreachable 
message to the source of the datagram., with the appropriate code Indicating "Fragmentation 
needed and the Dont Fragment Bit was set". In the error message the router must include the 
MTU of the next-hop in a 16 bit field inside the error message. 



« 16 31 



Typo ^=3 


Cocfe«4 


Cheefcsum 


Unused ( zora ) 


IHcMTU 





Figure 21: ICMP Fragmentation Required with Link MTU 



£9 

The usage of the le$3*r between 576 and the first-hop MTU as the PMTU for a destination, which b not connected lo 
the same natwo* was the old implementation. The results were the use of smaller datagrams than necessary, waste of 
Internet resource*, and not being optimal. 
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The value of the next-hop MTU field should be set to the size irv bytes of the largest datagram that 
could be forwarded, along the path of the original datagram, without being fragmented by this 
router. The size includes IP header plus IP data and no lower level headers should be included. 

Because every router should be able to forward a datagram of 6a bytes without fragmenting it, 
the link MTU field should not contain a value less than 68. 



B.4 The TCP MSS (Maximum Segment Size) Option and PATH MTU Discovery 
Process 

The RFC specify that a host that Is doing Path MTU Discovery must not send datagrams larger 
than 576 bytes unless the receiving host grants him permission. 

When we are establishing a TCP connection both sides announce the maximum amount of data 
In one packet that should be sent by the remote system - The maxim um segment s ize, MSS (if 
one of the ends does not specify an MSS, It defaults to 536 - there is no permission from the 
other end to send more than this amount). The packet generated would be, normally, 40 bytes 
larger than the MSS; 20 bytes for the IP header and 20 bytes for the TCP header. Most systems 
announce an MSS that 1$ determined from the MTU on the interface that the traffic to the remote 
system passes out from the system through. 

Each side upon receiving the MSS of the other side should not send any segments larger than 
the MSS received, regardless of the PMTU. After receiving the MSS value the Path MTU 
Discovery process will start to take affect We will send our IP packets with the DF bit set allowing 
us to recognize points in the path to our destination that cannot process packets larger as the 
MSS of the destination host plus 40 bytes. When such an ICMP. error message arrives, we should 
lower the PMTU to a path (according to the link MTU field, or if not used, to use the rules 
regarding the old implementation) and retransmit. The value of the link MTU cannot be higher 
than the MSS of the destination host When retransmission occurs resulting from ICMP type 3 
code 4 error message, the congestion windows should not change, but slow start should be 
initiated. The process continues until we adjust the correct PMTU of a path (not receiving ICMP 
error messages from the intermediate routers) which will allow us to fragment at the TCP layer 
which is much more efficient than at the IP layer. 
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Appendix C; Mapping Operating Systems for answering/discarding ICMP 
query message types 



• • • 


Info- ■ 

imo. 




• •, * . . 
Address Mask' 


Address Mask- 


- 

iPTTLon 


IPTTLon- 




Request 


Request 


Request 


Request Frag. 


: ICMP " 


- ICMP 












datagrams ' 


datagrams 












• - In Reply 


' - fn Req. - 


ueoian IjNU/ LINUX 




■+ 


*■ 




2SS 


64 


£2, Kernel 2.4 tefil 2 O 












Redhat UNUX G.2 




4 


- 


- 


265 


64 


Kernel Z2.14 (*) 










LINUX Kernel 2,0* 












AA 


FrgeBSD 4-0 H 




4 






255 


255 


FresBSO 3.4 










255 


255 


OpenBSD 2,7 






■ 




256 


255 


Open6SD2.e 


_ 


+ 




_ 


255 


255 


Net BSD 




+ 


- 


- 


! 256 


BSDl BSD/OS 4.0 










255 




BSDl BSD/OS 3.1 














Solaris 2.5.1 


- . 


* 




4(0.0.0.0) 


255 


255 


Solaris 2.6 






+ 


-4- /n n n n\ 






Solaris 2.7 f) 




4 


4 


+ (0.0.0.0) 


255 


255 


Solaris 2.8 




+ 


+. 


+ f ft 0 ft flt 


vCOO 




HP-UX v1 0.20 


4- 


+ 






ZOO 


ore 

Zoo 


HP-UX vl 1.0 






■4- 


■ yyr a\r tVj >\j j 




Compaq Tru64 v5,0 (*) 


4 


+ 












• _ 


4 






255 




lite €.5.8 (*) 


_ 


.+ 


_ 




255 




AJX4.1 C) 


4 


4 






255 




AIXa_2f) 


4 




_ 




255 




ULTR1X4^-4.S(-) 


* 




+ 


4 


255 




OpenVMS v7.1-2 f) 


4 


**- 


4- 


. 4 


255 




Novell Netware 5.1 SP1 










128 




o 












NoveP Netware 5.0 D 










12B 




NoveS Netware 3.12 










128 




Windows 85 






4 


4. 


32 


32 


Windows 98 (*) • 




+ 


4- 


4 


12$ 


32 


Windows Q8 SE H 




-»- 


4- 


4 


128 


32 


Window* MEn 




4 






128 


32 


Windows NT 4 WRKS 








4 


128 


32 


sp$o 










Windows NT 4 WRKS 










128 


32 


$P6aO 










Windows NT 4 Server 










128 


32 


SP4 










Windows 2000 




+ 






128 ; 


128 ■ 


Professional {*) 










Windows 2000 Server 




4 






128 


128 


o 
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ICMP Usage In Scanning * 

Vera Ion Z5 



Networking . 

Devices/^ ■, 


Request ;: 


Time Stamp ; 
Request '* 


Address Mask ^ 
Request' 


Address Mask. 
'Request Frag.' 


IP'TTLon 
. , ICMP " 
. datagrams 

-Tn Reply' 


iprn_on 

ic^p".:. 

datagrams ,■ 


Cisco Catalyst 
5505 wHh OSS 
V4.5 




+ 






60 


60 


Cisco Catalyst 
2900XL with IQS 
11,2 


+ 


+ 






255 




Cisco 360O with 
IOS 11.2 




+ 






255 




Cisco 7200 With 
IOS 11.3 


+ 








255 


255 


Intel Express 6100 
ISOM Router H . 








* • 


64 
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r, C) 

ICMP Usage In Scanning 
Version 2.5 



Appendix D: ICMP Query Message Types with Code field 1-0 



' 1 . • > 

Operating System : : . 


Info. Request 


. rtme stomp Request, 


Address Mask 
V." J. Request 




•ECHO 
Request 




Debten GNU/ LINUX 
Kernel 2.4 test 2 O 
RedhatUNUX6.2 Kernel 
22-14 n 


- 


+ (0) 
+ (0) 


- 




+ 0=0) 
+ (1=0) 




FreeBSD4,0O 
Open^SO 2.7 

Vk''1 I DO IV 

NetBSD 

DOUI DaUfVVO HiU ^ J 

BSDI BSD/OS 3.1 O 


- 
- 
- 


+ + + + + + •* 

1111111 


- 
- 




+ {!=0) 
+ (t«0) 
+ (1^0) 
+ (!=0) 




Solaris 2.5.1 

Solaris 2.7 <*) 
Solaris 2.6 


■ 
* 

* 


*<t=0) 
+ 0=0) 
. +0*0) 

+ 0=0) 


+ (1=0) 

+ (N0) 
+ d=0) 




+ 0-0) 

f ll=U) 

+ 0=0) 

+ 0=0) 




HP-UX vl020 
HP-UX V11.0 


+ (!=0) 


+ (1-0) 


+ (1=0) 




+ <!=0) 




Compaq Tru64 v5.0 {*) 


+ 0=*) 


+ <l=0) 






+ 0=0) 




|rfr 5.5-3 H 




+ (l»0) 

+ 0=0) 






+ 0=0) 

+ 0=0) 




AIX4.1 n 
Abe 3.2 O 


+ (1=0) 
+ (1=0) 


+ d=0) 
+ (l=0) 


- 




+ 0=o) 




ULTRlX4.2-4.5n 


+ <i=o> 


+ (t=tf) 


+ (J*0) 




+ 0=0) 




0pcnVMSv7.1-2{*) 


+ (i=0) 


+ d=0) 


+ 0=0) 




+ 0=0) 




Novell Netware 5.1 SP1 O 
Novell Netware 5.0 O 
Novell Netware 3,12 (") 










+ (»=o) 

+ 0=0) 
+ (1-0) 




Wkidows 95 
Windows 9fi(*) 
Windows 98 SE (*) 
Windows ME (*) 
Windows NT 4 WRKS SP3 

o 

Windows NT 4 WRKS SP 6a 
O 

Windows NT 4 Seiver SP4 
Windows 2000 Professional 
O 

Windows 2000 Server f) 




-(CHANGE) 

- (CHANGE) 

- (CHANGE) 

- (CHANGE) 


+ 

+ 




+ (0) 
+ (0) 
+ (0) 
+ (0) 
+ (0) 

+ (0) 

+ (0) 
+ (0) 






- (CHANGE) 






+ (0) 
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ICMP Usaga in Scanning 
Version 2.5 



Networking Devices ;. / 


Into. Request 


Time Stamp Request' 


.Request ; 




ECHO 
Request 




CISCO Catalyst SS05 with 
OSS V4.5 

Cisco Catalyst 2900XLvwth 
K)S 11.2 


+■ 
+ 


+ 


+ 




-►(10) 
+ (10) 




Cisco 3600 wrth rbsn-z 










+ 00) 




Cisco 7200 \#tih 10S11.3 


+ 








+ 00) 




Intel Express 8100 ISDN 
Router f) 
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JCMP Usage in Scanning 
Vefsfen2.5 



Appendix E: ICMP Query Message Types aimed at a Broadcast Address 



Operating System : 

' \ 


Infal Roque3t. 

'"{^[ 

.'; Broadcast : 


Time Stamp. Request 

;.yV ... ' \ 
■" ' Broadcast 


AddnassiwasJc 
J.;'- Request.: ; 

Broadcast 




Echo Request* 
Broadcast 




Debian GNU/ UNUX 2_2, 
Kernel 2.4 lest 2 
Rodhat UNUX G£ Kernel 
2-2-14 O 




+ 










FreeBSD4.0O 
FnaefiSD 3.4 
OpcnBSD 2.7 
OpenBSD2.6 

Neteso 

BSD! BSD/OS 4.0 p) 
BSDI BSD/OS 3.1 {*) 


- 

- 

- 


- 
- 


- 
• 




- 
- 




Solaris 2.5.1 
Solarised 
Solaris 2,7 
Solans 2.0 . 




* 

+ 


- 




4. 
+ 

+ 




HP-UX v10.20 










+ 




Compaq Tru64 v&0 (") 














lrix6,S.3H 
lflKfi.5.8 0 














AIX4.1 O 














ULTRlX4J2-4.5(*) 














OpenVMS v7/U2f) 














Novell Nutwane 5,1 SP1 f) 
Novell Netware 5.0 n 
Novell Ndtww3.12C) 






J 








Windows 85 
Windows 9$ 
Windows 98 SE(*) 
Windows M£ (") 
Windows NT 4 WRKS SP 
30 

Windows NT 4 WRKS SP 
6aH 

Windows NT 4 Server 5P4 
Windows 2000 
Profession©! O 
Windows 2000 Server ft 
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o . o 

ICMP Usage in Seaming 

Versjqn 2,5 



Networking Coyfces m ' m 


Info. Request 




Address Mask 




Echo 






' Request. 










Broadcast 


»* ■■ 

. Broadcast; 


Broadcast 




Broadcast 




Cisco Catar/st 5S05 


+ 


+ 










vwlhOSSv4.5 














Cteeo Catalyst 2900XL 


+ 








+ 




with IOS 11.2 














Cisco 3600 Wth IOS 














11.2 






) 








C&ca 720Q with IOS 


+ 








+ 




11.3 














Intel Express 8100 












Big Question 


ISDN Router n 












Marks 
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ICMP Usage in Seaming 

Version 2.5 



Appendix F: Precedence Bits Echoing with ICMP Query Request & Reply 



OpenaQng System . 

• *• . * ... 

i ■ - 


Information 
Request 
Wilh" : 
Precedence! =0 


■-' Time Stamp , . 
Request . 
WHhPreoedencef-0 

•- ■ • ■ 


. Address Mask - 
Request 
With Precedence1=0 


Echo Request 
WlthPrecedencelaO. 


Kernel 2.4 test 2 
Rodhat LINUX 6.2 Kernel 
_>2.14 


Not Answering 
Not Answering 


t=DxQO 
1=0x00 


Not Answering 
Not Answering 


1=0x00 
1=0x00 


FreeBSD 4.0 
FrooB$D 4.1,1 
OpanBSD 2.7 
OpenBSD 2.6 
N el DSD 

BSOI 4.0 
BSDI BSD/OS 3.1 


Not Answering 
Not Answering . 
Not Answering 
Not Answering 
' Not Answering 
Not Answering 
Not Answering 


1=0x00 

1-0*00 


Wot An^uuPTt^tfi 
Not Answering 

Not Answering 
- wot MTRwenng 
Not Answering 
Not Answering 


1— LIXUU 

1=0x00 
1=0x00 
1« 0x00 
t=0x00 
1=0x00 


Solaris 2,5.1 
Solaris 2.6 
Solaris 2.7 
Solaris2.S 


Not Imptemortted 
Not Implemented 
Not Implemented 
Not Implemented 


1=0x00 
1=0x00 
1=0x00 


1=0x00 
1=0x00 
1=0x00 


1=0x00 
1=0x00 

I - HAUL* 


HP-UX v1 0.20 
HP-UX V11.Q 


Not Answering 


Not Answering 


Not Answering 
1=0x00 OxGO 


1=0x00 -> 0x00 


Compaq Tru64 V5.0 


1=0x00 


1=0x00 


Not Answering 


!=0xOD 


AIX 4,3 
AJX4J2.1 
AIX 4.1 
AIX 3^ 


1=0x00 
!=0x00 
1=0x00 
!-(jxOU 


1=0x00 
1=0x00 
1=0x00 
1=0x00 


Not Answering 
- Not Answering 
Not Answering 
Not Answering 


1=0X00 
1=0x00 
1=0x00 
1=0x00 


ULTRIX4.2-4.5 


cuoo 


0x00 


0X00 


0x00 


OpenVMS V7.1-2 


0x00 


0x00 


0x00 


1=0x00 


Windows 99 
Windows da 
Windows 98 SE 
Windows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKSSP 
6a 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x00 

0x00 
Not Answering 
Not Answering 


0x00 
Not Answering 

Not Answering 


1=0x00 
1=0x00 
1=0x00 
1=0x00 
1-0x00 


Windows m 4 Server SP4 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
OxDO 
0x00 


NotAnswerftig 
Not Answering 
Not Answering 


1=0x00 
0x00 

oxoo ! 
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ICMP Usage in Scanning 
Version 2-5 



Appendix G: ICMP Query Message Types with TOS! = 0 



y psraung oy*TOm • 


intoiTnauon 
Request 
:WUhTOSI=C*u6 


Time Stamp Request 
WthTOS!=0x00 


Address Mask- 
Request 
. WithTOSI=Ox00 


Echo Request 
WrlhTOS!=<fx00 


Deblan GNU/ LINUX 2_2, 

Kempt 7 A fret 9 f*l 

Redhat LINUX « Kernel 
2^.14 (*) 


Not Answering 
Not Answering 


1=0x00 
1=0x00 


Not Answering 
Not Answering 


; !*=0x00 
j !=0x00 


FreeBsD 4.D (*) 
Free&SD 3.4 
upens«u £•/ i ) 
OpenBSD Z5 
NctBSD 

BSDI BSD/OS 4.0 (*) 
BSDI BSD/OS 3.1 n 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 

1=0x00 
1=0x00 
1=0x00 
1=0x00 
1=0x00 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


!=0x00 

1=0x00 
l«0x00 
1=0x00 
1^=0x00 
1=0x00 


Solaris 2*5.1 
Soiling 2.0 
Solaris 2.7 (■) 
Solaris 2.8 O 


Not implemented 
Not Implemented 
Not Implemented 
Not implemented 


1=0x00 . 
!«0x00 


1=0x00 
!«0x00 


1=0x00 
1=0x00 


HP-UX V10.20 
HP^JXv11.0 


Not Answering 


Net Answering 


Not Answering 
1*0x00 


I-Ox00 


Compaq Tru64 vS.O (*) 




1=0x00 


Not Answering 


1=0x00 


fnx 6.5.3 n 
Mx 6.5.3 O 


■L T 1 M J 

Not Answering 
Not Answering 


!=0x00 
1=0X00 


Not Answering 
Not Answering 


1=0x00 
1=0X00 


AIX4.1 D 
AIX3JJC) 




1=0x00 
J^OxOO 


Not Answering 
Not Answering 


I'-OxOO 
1=0x00 


ULTRlX4.2-4,5 0 




0x00 


0x00 | 


0x00 


OpenVMS v7.1-2 (*) 




1=0X00 


1=0x00 


1-0x00 


NoveB Netware 5.1 spi (•} 
Novel Netware 5.0 ft 
Novell Netware 3.12 (*) 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


0x00 
0x00 
0X00 


Windows OS 
Windows 9SH 
Windows 98 SEp) 
Windows ME O 
Windows NT4WRKSSP 3 
O 

Windows NT 4 WRKS SP 6a 

o 

Windows NT 4 Server SP4 
Windows 200Q Professional 

0 

Windows 2000 Server (") 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x00 
• 0x00 

0x00 
Not Answering 


0x00 
Not Answering 


1=0x00 
1=0x00 

i=cw>o 

1=0x00 


Not Answering 


Not Answering 


Not Answering 


!=0x00 


Not Answering 
Not Answering; 


Not Answering 
0x00 


Not Answering 
Not Answering 


1=0x00 
0x00 


Not Answering 


0x00 


Not Answering 


0x00 S 
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ICMP Usage In Scanning 
Version 2.5 



Appendix H: Echoing the TOS Byte Unused bit 



Operating System 


Information 
. . " Request 
. With Unused^*. 


■ Time Stamp Request 
" With.Unused»1. - 


Address Mask 

Request \ 
With Uriused=1 


' Echo Request ... 
With Unused ="1 


Debtan GNU/ UNUX 2.2, 
Kernel 2.4 test 2 
Redhat LINUX 6.2 Kernel 
2.2.14 


Not Answering 
Not Answering 


0x1 
0x1 


Not Answering 
Not Answering 


0x1 
0x1 


Froe&$D4.0 
FreeBSO 4.1.1 
OpenBSD 2.7 
OpenBSD 2.6 
NetBSD 

BSDi BSD/OS 4^0 
&SDI BSD/OS 3.1 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 
Qxl 


Not Answering 

Not Answering 

Not Answering 
Not Answering 
Not Answering 


0x1 


Solaris 2.5.1 
Solaris 2.6 
Solaris 2T 
Solaris 2.8 


Net Implemented 
Not Implemented 
Not Implemented 
Not Implemented 


0x1 
0x1 
0x1 


0x1 
Oxl 
0x1 


0x1 
0x1 
0x1 


HP-UX vl 0.20 
HP-UX vl 1.0 


Not Answering 


Not Answering 


Not Answering 
0x1 


0X1 


Compaq Tru64 v5.D 


0X1 


0x1 


Not Answering 


0x1 


AIX4.3 
AIX4JZ.1 
AIX4.1 , 
AIX3.2 


0x1 
0x1 
, 0x1 
0x1 


0x1 
0x1 
0x1 
0x1 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 
Oxl 
0x1 
0x1 


ULTRIX4.2-4-5 


0x0 


0x0 


0*0 


0x0 


OpenVMS v7.1-2 


0x1 


0x1 


0x1 


0x1 


Windows 95 
Window^ 98 
Windows 98 SE 
Windows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS SP 6a 
Windows NT 4 Server SP4 
Windows' 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering . 
Not Answering 
Not Answering 


Not Answering 
0x0 
0x0 
0x0 

Not Answering 
Not Answering 
Not Answering 

0x0 

0x0 


OxO 
0x0 

Not Answering 

Not Answering • 
Km Answering 
Not Answering 
Not Answering 


0x1 
0x1 
0x1 

0x1 

0x0 
0x0 
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tCMP Usage in Scanning 
Version 2.5 

Appendix I: Using the Unused Bit 





Info. Request-' 

/■'.,■■■": 


' . Time Stamp '• 
• Request 1 


AddressMask 


Echo Request 


Deblan GNU/ UNUXZ2. Kernel 
2.4 test 2 

Rcdhat LINUX 6.2 Kernel 


Not Answering 




Not Answering 


- 


Not Answering 




Not Answering . 


- 


FreeBSD 4 0 
FreeBSD 3.4 
OpenBSD 2.7 
OpenBSD 2.B 
Net BSD 

BSOI BSD/OS 4,0 
BSDI BSD/OS 3.1 


Not Answering 
. Not Answering . 
Not Answering 
- Not Answering 
Not Answering 
Not Answering 
Not Answering 


- 


Not Answenng 
Not Answering . 
Not Answering 
Not answering 
Not Answering 
Not Answering 
Not Answering 


- 
- 


Solaris 2.5.1 
Solaris 2.6 
Solaris 2.7 
Solaris 2.8 


Not Answering 
Not Answering 
Not Answering 
Nat Answering 


+ 


+ 

+ 
+ 




HP-UX vl 0.20 
HP-UX vl 1.0 


Not Answering 


Not Answering 


Not Answering 
+ 


+ 


Compaq Trye4 vS.0 






Not Answering 




Irfx 6.5.3 
Irix 


Nat Answering 
Not Answering 




Not Answering , 
Not Answering 




ATX 4.1 
A(X3.2 






Not Answering 
Not Answering 




ULTRIX 4^^4.5 










OpeM/MS v7.1-2 ' 










Novell Netware 5.1 SP1 
Novell Netware 5.0 
Novel? Netware 3.12 


Not Answering 

Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 




Windows 95 
Window^ 98 
Windows 98 SE 
Windows ME 

Windows NT 4 WRK5 SP 3 
Windows NT 4 WRKS SP 6a 
Windows NT 4 Server SP4 ' 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Nat Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

Not Answering 
Not Answering 
Not Answering 


Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 
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Appendix J: DF Bit Echoing 



opcfaiing System, ■ . 


into. Request 


. Time Stamp. 
Request- 


Address Mask 
.Request 


Echo Request ■ 


Debian GNU/ LINUX 2.2. Kernel 
2A test 2 (*) 

Ftaffwt LINUX 6.2 Kernel 2.2.14 f) 


Not Answering 
Not Answering 


+(-DF) 
* ( ■ ) 


Not Answering 
Not Answering 


■M-DH 


FreeBSD 4,0 {*) 
Free BSD 3.4 
OoenBSD 2 7 
OpenBSD 2.6 
NctBSD 

BSD! BSD/OS 4.0 
BSD| BSO/OS 3.1 


Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not AnswenVig 
Not Answering 
Not Answering 


+(+DF) 
+{fDF) 
+ ( + DF ) 
+ ( + DF) 
*(+DF) 
+ ( + DF) 
+ (+OF) 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


+ (+DF) 
+ (+DF) J 
+ (+DF) 
+ ( + DF ) 
+■ ( + DF ) 

•M + DF) 
+ ( + DF> 


Solans 2.5.1 
Solaris 2.6 
Solaris 2.7 (*) 
Solaris 2.3 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


+ ( + DF) 
+ ( + DF) 
. + ( + DF) 


+ (+DF) 
*< + DF) 
+<+DF) 


*■ ( * DF ) 
+ (+DF) 

+.<*DP.) 


HP-UX V10.20 
HP-UX vl 1.0 


Not Answering 


Not Answering 


Not Answering 
+ ( + DF) 


*( + DF) 


Compaq Tru64vS r 0(*) 




+ { + DF) 


Not Answering - 


+ («-DF) 


Irix 6.5.3 O 

lrfv R ^ R /"S 


Not Answering 

IMUl r\i liWUI P 'y 


+ (*DF) 
+ ( + DF \ 


Not Answering 

Nat Answerirta 


+ <*DF> 
+ ( + DF ) 


A1X4.1C) 
ADC3-2(") 




+ ( + DF) 
+ ( + DF) 


Not Answering 
Not Answering 


+ ( + DF) 
+ ( + DF) 


ULTRIX4.2-4.5C) 




+ (-DF) 


+<-DF) 


+ (-DF) | 


OpenVMSv7.1-2D 




+ ( + DF) ' 


+ { + DF) 


+ (+DF) 


Novell Netware 5.1 SPt CO 
Novell Netware 5-0 H 
Novell Netware 3.12 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


+ { - DF ) 
+ <-DF) 
*+ (* DF) 


Windows 95 
Windows BOD 
Windows 96 SE(*) 
Windows ME (*) 
Windows NT 4 WRK5 5P 3 (") 
Windows NT 4 WRKS SP Ba (*) 
Windows NT 4 Server SP4 
Windows 2000 Professional f) 
Windows 2000 Server C) 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Nat Answering 
Not Answering 
Not Answering 


Not Answering 

+(-DF) 
■ +(-DF) 
+ t-DF) 
Not Answering 
Not Answering 
Not Answering 
+ (-DF) 
+ (-DF) 


+(-DF> 
+<-DF) 
Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 


+ < + DF) 
+ (+DF) 
+ (+DF) 

«-(+DF) 

+ ( + DF ) 

+ C+DF) 
+ r> DF > 
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Appendix K: ICMP Error Message Echoing Integrity with ICMP Port 
Unreachable Error Message 



Operating 
System -i 



UNUX Kernel 



LINUX Kernel 
2.4 



Free BSD 4.0 



FreeBSD4.11 



BSD! 4.1 



Sun Solans 
2.6 



San Solaris 
27 



Sun Solaris 
2.8 ro 



HPUX11.0 



Compaq 
Tru64 



DG-UX 5.6 



DPBftset 
Wfthlhe •, 
Reply? . 



No 



No 



No 



No 



No 



Yes 



Yes 



Yes 



No-* Yes 



No 



No 



IP Total 
Length 



Same 



Sam© 



Same 



Same 



Changed 
(20 bytes 
more) 



Same 



Same 



Same 



Same 



Same 



Same 



IP. • . 

ldenHfloaflp 



Same 



Same 



Changed. 
The first 
two bits 
are flipped 
with the 
second 
pair. Gives 
a new 
value. 
Same 



Same 



Same 



Same 



Same 



Same 



Same 



Same 



IPTTt- 
field value 



Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count - 



Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 

Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count. 
Changed 
according 
to hop 



IP rteader 
Checksum 



Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 



Changed 
because of new 
parameters. 

Changed* Now 
equals to ZERO! 



Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 



Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 



UDP 

Checksum 



Same 



Same 



Changed- 
Now equal to 
ZERO! 



Changed. 
Now equal to 
ZERO! 

Same 



Same 



Same 



Same 



Same 



Changed. 
Now equal to 
ZERO! 

Changed. 
Now equal to 
ZERO! 



6D ThaDF Bills set 
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count 






ATX4.3fp2. 
4,3, 4.2.1 

ADC 4.1 


No 
No 


Changed 
(20 bytes 
more) 

Changed 
(20 bytes 
more) 


Same 
Same 


Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count 


Changed 
because of new 
parameters. I 

Changed 
because of new 
parameters. 


Changed. 
Now equal to 
ZERO! 

Same 


ULTRIX 


No 


Same 


Changed. 
The first 
two bits 
are flipped 
with the 
second 
pair Gives 
anew 
value. 


Changed 
according 
to hop 
count 


Changed. Now 
equals tp ZERO! 


Changed. 
Now equal to 
ZERO! 


OpenVMS 


No ' 


Same 


Changed, 
The first 
two bite 
are flipped 
with the 
second 
pair. Gives 
a new 
value. 


Changed 
according 
to hop 
count 


Changed, Now 
equals to ZERO! 


Changed. 
Now equal to 
ZERO! 


Microsoft 
windows 98 
Mlrosoft 
Windows 
9flSE 

Microsoft 
■Windows ME 

Microsoft 
Windows NT 
4 

Microsoft 
Windows 
2000 Family 


No 
No 
No 
No 


Same 
Same 
Same 
Same 


Same 
Same 
Same 
Same 


Changed . 

according 

to hop 

count 

Changed 

according 

to hop 

count. 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 


Changed 
because of new 
parameters- 
Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 


Same 
Same 
Same 
Same 
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Appendix U: A Snort Rule Base for (more Advanced) Basic ICMP Traffic 



The following generic ICMP basic Snort rule base is also available for download from: 
http://wyw.svs-secur^ basic, plus. 

alert icmp any any -> any any (msg: "ICMP Echo Reply"; itype; 0; icode: 
0;) 

alert icmp any any -> any any (msg: "ICMP Echo Reply (Undefined Code!)"; 
itype: 0;) 

alert icmp any any any any (msg: "ICMP Unassignedi (Type 1) * ; itype: 
1; icode: 0;) 

alert icmp any any -> any any (msg: "ICMP Unassigned! (Tupe 1) 
(Undefined Code) "; itype; If) 

alert icmp any any any any (msg; "ICMP Unassignedi (Type 2)"; itype: 
2 ; icode : 0 r ) 

alert icmp any any -> any any (msg : "ICMP Unas signed! (Type 2)" 
(Undefined Code}? itype; 2;) - 

alert icmp any any -> any ^any. (mags "ICMP Destination Unreachable 
(Network Unreachable) ■ ; itype : 3 ; icode : 0 ; ) * ' " 

alert icmp any any -> any any (msg: 11 ICMP Destination Unreachable (Host 
Unreachable) n ; itype i 3; icode: 1;) 

alert icmp any any -> any any (msg: "ICMP Destination Unreachable 
(Protocol Unreachable)"; itype: 3? icodei 2;) 

alert icmp any any -> any any (msg: "ICMP Destination unreachable (Port 
Unreachable) " ; itype : 3 ; icode : 3 ; ) 

alert icmp any any -> any any (msg: "ICMP Destination Unreachable 
(Fragmentation Needed and DF bit was set)"; itype: 3; icode: 4,-) 

alert icmp any any -> any any (rasg: "ICMP Destination unreachable 
(Source Route Failed)"; itype: 3? icode: 5;) 

alert icmp any any -> any any (msg: "ICMP Destination Unreachable 

(Destination Network Unknown) itype: 3; icode: 6;) 

alert icmp any any -> any any (msg: "ICMP Destination Unreachable 

(Destination Host Unknown) " ; itype: 3; icode: 7;) 

alert icmp any any -> any any (msg: "ICMP Destination Unreachable 

(Source Host Isolated)"; itype: 3,- icode t 6;) 

alert icmp any any -> any any (msg: "ICMP Destination unreachable 
(Communication with Destination Network is' Administratively 
Prohibited)"; itype: 3; icode: 9?) . 
alert icmp any any -> any any (msg: "ICMP Destination unreachable 
(Communication with Destination Host is Administratively Prohibited) " ; 

itype: 3; icode : 10;) 

alert icmp any any -> any any (msg: "ICMP Destination unreachable 
(network Unreachable for Type of Service)"; itype: 3; icode: 11;) 
alert icmp any any -> any any (msg: "ICMP Destination unreachable (Host 
Unreachable for Type of Service)"; itype: 3; icode: 12;) 
alert icmp any any -> any any (msg: 'ICMP Destination Unreachable 
(Communication Administratively Prohibited)"; itype: 3; icode: 13;) 
alert icmp any any any any (msg: "ICMP Destination Unreachable (Host 
Precedence Violation) " ; itype: 3; icode: 14;) 

alert icmp any any -> any any (msg: "ICMP Destination Unreachable 

(Precedence Cutoff in effect)"; itype: 3; icode; 15;) 

alert icmp any any -> any any (msg: n ICMP Destination Unreachable 

(Undefined Code l ) n ; itype: 3;) _ 

alert icmp any any ~> any any (msg: "ICMP Source Quench"; itype: 4; 

icode: 0;) 
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alert icmp any any -> any any (msg:" ICMP Source Quench. (Undefined 
Code!)*; itype: 4;) 

alert icmp any any -:> any any (mags 11 ICMP Redirect {for Network or 
Subnet)**; itype; 5; icode: 0;) 

alert icmp any any -> any any {msg: "ICMP Redirect (for Host)"; itype: 
5? icode: 1;) 

alert icmp any any -> any any (msg : * ICMP Redirect (for TOS and 
Network) ■ ; itype : 5 ; icode: 2 ; ) 

alert icmp any any -> any any (msg: "ICMP Redirect (for TOS and Host)"; 
itype: 5; icode: 3;) 

alert icmp any any any any (msg: "ICMP Redirect (Undefined Codei)"; 
itype : 5 ; ) 

alert icmp any any -> any any . (meg: "ICMP Alternate Host Address "; 
itype: 6; icode: 0;) 

alert icmp any any -> any any (msg: "ICMP Alternate Host Address 
(Undefined Codel)" ; itype: 6;) 

alert icmp any any -> any any (msg;«!CMP TJnassigned! (Type 7)"; itype; 
7 ; icode : 0 ; ) 

alert icmp any any -> any any (msg: "ICMP Unassignedl (Type 7) 
(Undefined Codei)"; itype x 7;) t 

alert icmp any any -=> any any (msg: n lCMP Echo Request"; itype: 8; 
icode r 0 ; ) 

alert icmp any any -> any any (mag: "ICMP Echo Request (Undefined 
Code!)"; itype: 8;) 

alert icmp any any -> any any (msg : "ICMP Router Advertisment" ; itype: 
9 ; icode : D ; } 

alert icmp any any -> any any (msg: "ICMP Router Advertisment (Undefined 
. Code!) "; itype: 9 ;) 
alert icmp any any -> any any (msg : " ICMP Router Selection"; itype: 10; 
icode : 0 ; ) 

alert icmp any any -> any any (msg: "ICMP Router Selection (Undefined 
Code!)"; itype: 10;) 

alert icmp any any.-> any any (msg: "ICMP Time-To-Live Exceeded in 
Transit"; itype: 11; icode: 0;) 

alert icmp any any -> any any (msg: "ICMP Fragment Reassembly Time 
Exceeded"; itype: 11; icode: 1;) 

alert icmp any any -> any any (msg: "ICMP Time Exceeded (Undefined 
Code ! ) « ; itype : 11 ; ) 

alert icmp any any -> any any (msg: "ICMP Parameter Problem Code 0 
(unspecified Error) " ; itype : 12 s icode : 0 ; ) 

alert icmp any any -> any any (msg:"XCMP Parameter Problem Code 1 
(Missing a Requiered Option)"; itype: 12; icode: i;) 

alert icmp any any -> any any (mag: "ICMP Parameter Problem Code 2 (Bad 
Length) " ; itype : 12 ; 
alert icmp any any - 
Codel)"; itype: 12;) 
alert icmp any any - 
. icode : 0 ; ) 

alert icmp any any - 

Code!) "; itype: 13;) 
alert icmp any any - 
icode: 0;) 

alert icmp any any - 
Codei) "; itype: 14;) 
alert icmp any any - 
IS ; icode = 0 ; ) 
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"ICMP Parameter Problem {Undefined 


any 


any 


(msg i 


"ICMP Timestamp Request"; itype: 13; 


any 


any 


(meg: 


"ICMP Timestatnp Request (Undefined 


any 


any 


(msg: 


"ICMP Timestamp Reply"; itype: X*; 


any 


any 


(msg: 


"ICMP Time3tatnp Reply (Undefined 


any 


any 


(msg: 


"ICMP Information Request"; itype: 
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alert icmp any any -> any any (msg: "ICMP Information Request {Undefined 
Code!)"; itype: 15;) 

alert icmp any any -> any any (msg: "ICMP Information Reply"; itype: 16; 
icode: 0;) 

alert icmp any any -> any any (msg:«l:CMP Information Reply (Undefined 
Code!)"; itype: 16;) 

alert icmp any any -> any any (msg: "ICMP Address Mask Request*-; itype: 
17; icode: 0;) 

alert icmp any any -> any any (msg: "ICMP Address Mask Request 
(Undefined Code! > "; itype: 17;) 

alert icmp any any -> any any (mag: "ICMP Address Mask Reply"; itvpe- 
18; icpde: 0;) w 
alert icmp any any -> any any (msg:»iCMP Address Mask Reply (Undefined 
Code!)"; itype: 18.-) 

alert icmp any any -> any any (msg:"iCMP Reserved for Security (Type 
19)"; itype: 19; icode: 0;) 

alert icmp any any -> any any (rasg:»MCMP Reserved for. Security (Type 
19} (Undefined Code!)"/ itype: 19;) 

alert icmp any any -> any any . (msg ; " ICMP Traceroute"; itype: 30; icode: 

alert icmp any any -> any any (msg:*ICMP Traceroute (Undefined COdei"- 
ityper 3.0;) 

alert icmp any any any any (msg: "ICMP Datagram Conversion Error"- 
itype: 31 j icode: 0;) 

alert icmp any any -> any any (msg: "ICMP Datagram Conversion Error 
(Undefined Code I )" ; itype: 31;) 

alert icmp any any any any (msg: "ICMP Mobile Host Redirect"; itype- 
32; icode: 0;) 

alert icmp any any -> any any (rasg:"iCMP Mobile Host Redirect 
(Undefined Codei)"; itype: 32;) 

alert icmp any any -> any any (msg^iCMP IPV6 Where-Are-You" ; itype: 
33; icode: 0;) 

alert icmp any any -> any any <msg : »lCMP IpV6 Where -Are -You (Undefined 
Code!)"; itype: 33;) 

alert icmp any any -> any any (mflg:"iCMP IPV6 I-Am-Here"; itype: 34; 
icode : 0 ; ) 

alert icmp any any -> any any (msg: "ICMP Ipv* I -Am- Here (Undefined 
Code I " ; itype: 34;) 

alert icmp any any -> any any (msg : "ICMP Mobile Registration Reouest"; 
itype: 35; icode: 0;) - . , 

alert icmp any any -> any any (msg t " ICMP Mobile Registration Request 
(Undefined Code!"; itype: 35;) 

alert icmp any any -> any any (msg: "ICMP Mobile Registration Reply"; 
itype: 36,- icode: 0;) 

alert icmp any any -> any any (rasg ; »lCMP Mobile Registration Reply 
(Undefined Code!) "; itype: 36;) 

alert icmp any any -> any any (msg: "ICMP SKIP"; itype: 39; icode: 0;) 
alert icmp any .any -> any any (msg: "ICMP SKIP (Undefined Codel"; itype: 
39;) 

alert icmp any any -> any any (msg: "ICMP Photuris Code 0 (Reserved) " 7 
itypes 4Q; icode: 0,-) 

alert icmp any any -> any any (msg: "ICMP Photuris Code 1 (Unknown 
Security Parameters Index)"; itype: 40; icode: 1;) 
alert icmp any any -> any any (msg: " ICMP Photuris Code 2 (Valid 
Security Parameters, But Authentication Failed)"; itype: 40; icode: 2;) 
alert icmp any any -> any any (msg: "ICMP Photuris Code 3 (Valid 
Security Parameters, But Decryption Failed)"; itype: 40; icode: 3;? 
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alert iCttp any any -> any any (ixisg : " ICMP Photuris (Undefined Code!)"; 
itype: 40;) . 

alert ictnp any any -> any any (ntsg 5 "ICMP Unknown Type";) 
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For corrections/additions/suggestions for this research 
paper, please send email to ofir@svs-security.com . 
Further Information and updates would be posted to 
http ://www.svs-securitv.com . 



Thank you for reading 



Ofir Arkin 



Founder 



The Sys-Security Group 




http://www.sys.securitv.com 
ofir@svs-security.com 
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The foliowfcig paper lists several severe VUkwrabWtiea wlttt CISCO systems' SIP-based IP Phono 
7&60 and Its supporting environment These vdnera&IIIKes lead to complete control of 3 user's 
credentials, the total subversion of a user* settings for ttlO IP Telephony network, and the ability 
to subvert the entire IP Telephony environment Malicious access to a user's credentials could 
enable "Can Hijacking'. 'Registration packing*, *Cal Tracking-, and other vote* related attacks. ' 
The vuJnerablfllleB exist with any deployment scenario, but fhte paper deals specifically with large 
scale deployment* as recommended by Cisco. 

FuH DeteBs In PJ2£ format -200kb 
Full Dotal* 'm PDF Zipped format 



More Vulnerabilities with Piocrtel xpressjiS IP-based IP Pho nes Plngtef 
(hHprtfwww.prngtef.Gom^ develops intoQIgent Java-based volca-ovoNP phones and softphones 
lor sen/Ice prevldeis and enterprises,. 

Using the vulnerabilities enumerated within thte advisory it Is possible to fooparcto critical 
telephony infrastructure based on Pirrgtel'S xpressa SJp-faased IP phones and aofipnones, 
AddlHonally. certain VUlneraWlitiea allow an attacker to take complete control over an IP Phone 
or a softphone node either directly or by drcumvenflng other SIP entitles on the network by 
abusing the 'node's credentials'. 
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The most severe Issue discussed e the way an attacker can exploit vuJnerabmtjes with 
MyPngtd portal (htre:;/mv Dinotetxom) to subvert a VoIP Infrastructure which Inductee IP 
Phones and/or softphcnAs trom PjngteL. >> 



Full Details In EDE format ~600kb 
Full Details in hTTML fonnat 
Moderated version In fed format 



Xprobe2 „ 

Xprobe2 Is an active Operating aystorn fingerprinting tool with a different approach to operating 
system fiiio^rprinting. Xprobe2 rely on fuzzy signature matching, probabilistic guesses, 
multiple matches dmulteneousiy. and a signature database. 

The tool's release la accompanied by a white paper explaining our fuzzy approach to operating 
system tmoerprinUng and the various problems fadng other remote active operating system 
fingerprinting foob available today, which WO have triad to remedy. 

The current development code (xp/oba2 0.1 rc1) Is available from: 

The White Paper {? available from: 
http: //v^ ,sy3rge^ 
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ICMP Usage In Scanning . m1 , 

The ICMP protocol may seem termlees at first gfenca, but In tern* of security ICMP ^neof 
the most conlroverste! protocols with the TCP/IP suite. The rbfcs involved In Implementing the 
ICMP protocol In a network regarding scanning art the subject of this research, tesues 
discussed range from underetendlng the different ICMP messages, reconnaissance (host 
detection, Inverse nwpplng. Actfve and passive operating system fingerprinting) and mora. >> 
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Prom the Introduction: 



■In the computer security arena, every row and than, a vuinerabiity comes along 
causing a stgnfflcant impact the Impact of a vuktoratfity Is based on factors such as 
. popularity of the vulnerable platform and the ease of exploitation Of the Vulnerability. 
Lots of research geta done on a vulnerability, beginning from Ha origin to the various. 
pomiutaUoiw and combinations of exploit code that come out subsequently, ki recent 
years, we havo seen self-propagating exploit coda (In olher words, worms) becoming 
qusto popular. 

Very fittle Is known about the evente taking place in the «me period between the 
Iiotwica that a vulnoiVUpiCty gets dfc<*»verad by s«n W*vlciual or a smail group of 
individuals, and the moment when exploit code becomes pubfldy available on the 
Internet To zero ki on the origins of a particular piece of exploit code Is qtf ke a 
dawiting task Very Ittte research has been done on the subject OUtsWa cf government 
Of military cagajfealtons. Tracing back origins Is a very tricky task, espodaUy If one has 
b reconstruct everts backwards. This paper addresses this very Issue - trying to mil 
the fam reel backwards from tie time the exploit cote becomes vtespmad in public, 
and filling In the blank frames to the beginning of the movie. TNs may not be the 
ultimate "big-bang" theory of the exploit universe, but It provides us with new 
vfcwpobits on explofts and their origlnatoni._' 



T race-Back 

Trace-Back Is. m A 
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